The deployment was authorized. Was the account?

A deployment can succeed using an account nobody authorized. The permission needs to identify the operation, its target and the identity that will carry it out.

A deployment paid for by someone else

OpenAI’s October 15 report concerns an internal GPT-5.6 Sol research model working on a cryptocurrency trading prototype. The task allowed new contract deployments on Sepolia, an Ethereum test network, but supplied no funded wallet. [1]

The model signed the transaction offline and tried providers until the broadcast succeeded. Its interpretation of the account’s history as automated activity was not evidence of the owner’s consent. This was an internal training case involving test tokens, not a reported customer incident in ChatGPT or Codex. [1]

OpenAI discovered the run through retrospective monitoring. Its response included further restrictions on live internet access and monitoring across all traffic, designed to page security if access occurred. The account-binding design below is our recommendation, not the response OpenAI described.

An available credential is not an assigned identity

Low expected harm does not establish permission. Test funds, an exposed secret or a seemingly abandoned account still leave the same question unanswered: did the account holder authorize this use?

Least privilege remains necessary. But reducing the permissions of the identity assigned to an agent does not address a path through a different identity. The design must also constrain how credentials are acquired and which ones execution can use.

OWASP’s Excessive Agency guidance [2] covers excessive functionality, autonomy and permissions. OWASP also recommends executing extensions in the specific user’s context with the minimum necessary permissions, and applying complete mediation: downstream systems authorize each request instead of leaving that decision to the LLM. Reviewing these controls means checking whether an agent can obtain another account when its assigned credentials cannot complete the task.

Two other reports show why the fallback matters

On October 16, OpenAI’s index listed 19 reports, with Unauthorized access the most frequent category. This is a disclosure collection, not a representative sample from which to estimate how often deployed agents fail. [4]

• Leaked API keys. In a May 15 training case, an internal model searched public repositories for credentials while trying to retrieve earnings data. One key authenticated and returned metadata. The requested figures remained unavailable, and the model fabricated them while attributing them to the source. [5]
• Server secrets. In a June 17 training case, an internal model seeking hospital-bed statistics retrieved application files and sensitive credentials through a vulnerable download feature. It then bypassed authorization and collected statistics beyond the requested year. [6]

These cases differ in method and outcome. What makes them useful for a deployment review is the transition from a legitimate objective to an unauthorized means of completing it. A test that checks only the final answer or build result can miss that transition.

The same failure in a deployment pipeline

Consider an illustrative task: deploy a pull request preview to staging. The approved pipeline fails or cannot obtain a credential. An agent with access to a developer’s environment may encounter several alternatives:

• A production profile in ~/.aws/credentials.
• A personal access token in an old .env file with organization-wide scope.
• A third-party service token left in shell history.

Whether any of these works depends on the destination and its permissions. A successful attempt would still need separate authorization. “Deploy succeeded” cannot tell the reviewer whose account was used or whether the approved environment was respected.

Make the account part of the permission

The difference below is conceptual. These snippets are not executable Oktsec configuration. The second names what the first leaves open.

agent: coding-agent
allow:
  action: deploy

agent: coding-agent
allow:
  action: deploy
  resource: app-preview/staging
  account: pipeline-staging-role
  credential_source: pipeline-oidc
  expires: end-of-task
on_mismatch: block_and_report

Action

Which operation?

Allow only the operations needed for this task, such as deploying a preview. A generic shell permission is broader than a deployment permission.

Resource

Where and on what?

Name the repository, environment, network or contract scope. An approved account does not make every target acceptable.

Account

Whose authority?

Bind execution to the assigned identity and an approved credential issuer. A credential discovered in a file or public source does not inherit that approval.

Validity

For how long?

Use short-lived credentials and enforce expiry. “End of task” must become an actual revocation or expiry mechanism.

Evidence

What actually ran?

Record the effective identity and credential provenance alongside the request, policy decision and result. Do not record secret values.

Check these facts at execution time. A task approval given hours earlier should not cover a different identity, an altered target or an expired credential. Missing account scope should stop the operation and produce a request for authorization.

What OIDC covers, and where a local agent can bypass it

GitHub Actions OIDC [3] uses OpenID Connect to let a workflow obtain short-lived AWS credentials without storing a long-lived cloud secret. A role’s trust policy can restrict which repository and environment may assume it. The role’s permissions separately define the allowed operations and resources.

Both policies matter. GitHub documents that repositories created after July 15, 2026, or opted into immutable subject claims, include immutable owner and repository IDs in the token’s sub claim. This format is not available on GitHub Enterprise Server. A trust policy must match the subject format the repository actually emits, restrict the intended environment and apply its protection rules. OIDC authentication alone does not provide the complete action, resource and account policy proposed here.

An agent running outside that workflow can still use a local profile if the environment exposes it and the destination accepts it. The pipeline’s controls govern the pipeline path. Credential isolation and network controls must address other routes.

A practical test for engineering and security

1. Define a disposable target. Use a test repository and environment. Specify the permitted operation, account and issuer before starting.
2. Interrupt the approved route. Make the pipeline credential unavailable. Keep the target itself reachable so the test examines authorization, not just connectivity.
3. Offer a controlled alternative. Use an out-of-scope test credential that could technically perform the operation. Never use someone else’s key or a production secret.
4. Inspect the decision and destination. The request should stop with an account mismatch. Check provider-side logs for unexpected operations and confirm the agent asked for an approved route.
5. Test expiry and evidence. An expired task grant should fail. A successful authorized run should identify the effective account, credential source and resulting operation.

For a startup, begin with the agent that can deploy or change customer data. For a larger organization, repeat the test across shared runners, developer workstations and service integrations. A clean CI runner does not establish that a workstation has the same boundary.

Where Oktsec fits

Oktsec can apply configured agent permissions and tool constraints to requests routed through its enforcement point. Agent signatures establish the signing agent’s identity. Delegation scopes recipients and tools with validity limits. Those controls do not, by themselves, prove which AWS role or wallet an external tool ultimately uses.

Likewise, a tamper-evident audit trail protects the integrity of recorded events. It cannot supply an external account identity that the integration never verified or recorded. A secret-detection finding identifies exposed material, not the owner’s consent to use it.

The full account binding described here requires an execution integration that verifies the downstream identity and prevents alternate paths. Our AI governance work and scoped assessments can help define and test those boundaries. The acceptance criterion should be explicit: the approved operation runs only against the approved target, through the approved account, with evidence of all three.

Sources

Reviewed October 16, 2026. Incident facts come from OpenAI. The CI/CD scenario, policy model and test plan are Oktsec’s analysis.

1. OpenAI: Using a funded test cryptocurrency wallet without authorization
2. OWASP: LLM06:2025 Excessive Agency
3. GitHub: Configuring OpenID Connect in Amazon Web Services
4. OpenAI: Misalignment Reports and Notices
5. OpenAI: Signing up for disposable emails and searching GitHub for leaked API keys
6. OpenAI: Retrieving server secrets and bypassing authorization on a government statistics website