Because approvals usually judge one action at a time, while attacks exploit the chain between actions. If the agent can read a secret, retry with another flag, or upload data through an allowed path, the prompt never sees the full sequence. The risk comes from permissive runtime reach plus human fatigue, not from the prompt itself.
Why prompt approvals miss the real secret exposure path
Prompt approvals are usually too narrow for coding agents because they evaluate a single request, not the full run of reads, retries, tool calls and uploads that follow. A secret can be exposed by context the prompt never surfaces, especially when the agent can inspect files, reuse tokens, or move data through an allowed channel without asking again.
That makes the problem one of runtime reach, not just intent approval. A human may approve “read this repo and fix the bug,” while the agent quietly encounters environment files, cached credentials or API keys and can continue operating with them inside the same permitted workflow.
AI Coding Agents Security Guide is the right starting point for understanding how secrets in agent context, over-scoped tokens and sandbox boundaries interact in real workflows.
Current guidance suggests treating approvals as one control layer, not the control boundary itself. If the agent can see secrets in workspace context or inherited environment variables, the approval prompt does not prevent exposure, it only records that the workflow was allowed to begin.
How the attack chain bypasses human review
The practical weakness is chaining. An agent may be approved to open a file, then use the contents to authenticate somewhere else, then retry with altered parameters, then export results through a permitted upload or commit path. Each step can look acceptable in isolation while the combined sequence creates the exposure.
That is why secret loss often looks like “normal work” in logs. The agent did not need to ask for a separate prompt to read a token, copy it into a later tool call, or send it to an external destination that was already allowed for the task.
Guide to the Secret Sprawl Challenge is useful here because it frames how hardcoded credentials, CI/CD exposure and weak rotation practices turn ordinary developer workflows into secret leakage paths.
Secrets Management Guide adds the operational answer: reduce the number of places where an approved agent can encounter usable secret material in the first place.
What good control looks like for coding agents
Good control is less about asking the model “do you approve this?” and more about limiting what the agent can reach, retain and reuse during execution. That means short-lived credentials, scoped access, isolated workspaces and explicit barriers around sensitive files, secrets stores and outbound exfiltration paths.
The key design question is whether the agent can complete its work without ever handling durable secret material. If the answer is no, the workflow should be redesigned rather than trusted to prompt-time judgment alone.
OWASP Non-Human Identity Top 10 is directly relevant because it addresses overprivilege, long-lived secrets and improper offboarding for non-human actors that operate with real access.
RFC 7523: JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants is a useful reference when teams need a stronger alternative to shared secrets for service-to-service authentication in agentic workflows.
Risk and Threat Considerations
Secret exposure risk rises when a coding agent can combine broad read access with outbound tooling and a human supervisor who sees only the initial prompt. The attacker does not need the agent to “approve” theft, only to make the secret accessible somewhere in the action chain.
Failure mechanism: permissive runtime access, reusable credentials and multi-step tool execution let the agent harvest or relay secrets after the approval event, while human review remains focused on the first instruction rather than the full sequence.
Impact: exposed API keys, tokens or source credentials can lead to repository access, cloud misuse, data exfiltration, destructive actions or lateral movement, especially when the same secret works across environments or survives beyond the task.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 define the specific risk controls and attack patterns relevant to this topic.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Coding agents expose secrets through workspace and runtime access. |
| NHI-05 — Overprivileged NHI | Agent approvals fail when the runtime identity can do too much. | |
| NHI-07 — Long-Lived Secrets | Long-lived tokens make post-approval secret reuse and exfiltration easier. | |
| Recommendation — Restrict agent access to secret material and eliminate reusable credentials from its execution path. Scope agent credentials to the minimum actions and repositories needed. Replace durable secrets with short-lived credentials and rotate exposed tokens quickly. | ||
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | The risk comes from chained tool actions after an allowed prompt. |
| ASI03 — Identity & Privilege Abuse | Agent runtime privilege determines whether approvals can be bypassed through action chains. | |
| Recommendation — Constrain the tools an agent can call and monitor chained actions for abuse. Bind agent permissions to narrowly scoped identities and verify every privileged tool call. | ||
Practitioner Guidance
What to verify: confirm whether the agent can read .env files, shell history, build logs, secret stores, browser sessions or mounted credentials during the task. If any of those are reachable, assume the approval boundary is weaker than the runtime boundary.
Decision rule: if a coding agent can authenticate with a secret that also grants broad repository, cloud or deployment access, treat that secret as production exposure and rotate it on a short fuse, even if there is no evidence of misuse.
What practitioners underestimate: fatigue and trust accumulation matter as much as permissions. Repeated benign approvals make teams less likely to notice when the agent starts handling secrets as part of a normal-looking workflow, so review should target the reachable data path, not the wording of the prompt.
Practitioner takeaway: Prompt approval is a request gate, not a secrecy boundary, so the real control objective is to keep coding agents from ever entering a workflow where secret material is both reachable and reusable.