The main failure is that the agent can treat attacker controlled input as routine work and execute malicious code inside a trusted session. If that session also holds ambient credentials, the blast radius expands fast. A single malicious test or repository can expose API keys, tokens, private messages, and source code unless execution is isolated and secrets are tightly scoped.
Why Untrusted Tickets and Pull Requests Break the Trust Boundary
When a coding agent can read untrusted support tickets or pull requests in the same runtime that can also reach production secrets, the problem is not the ticket or PR by itself. The break is the collapse of trust boundaries. Input that should be treated as adversarial can steer the agent, and the agent’s own execution context can turn that steering into secret exposure, code execution, or unauthorized changes.
This is why secure agent design treats prompt-like content, repository content, and operational secrets as separate trust zones. Once they share one execution environment, the agent is no longer just processing text, it is effectively acting with the authority of whatever credentials, tokens, or source access are already present.
For teams deploying coding assistants, the important distinction is between reading and acting. A model can summarize an issue safely, but an agent with tool access, filesystem access, or shell access can convert malicious instructions embedded in a ticket or PR into real side effects. That is the moment the environment stops being a productivity aid and becomes an attack surface.
How the Failure Turns Into Secret Exposure or Code Execution
The unsafe pattern is ambient authority. If the agent inherits broad access to repositories, package registries, cloud APIs, chat systems, or deployment tools, then any attacker-controlled input it processes can be used to trigger actions that were never intended by the user who opened the ticket or reviewed the PR. A malicious test, diff, build step, or linked artifact can cause the agent to inspect files, fetch dependencies, run commands, or leak environment data.
That is why separation matters so much in practice. A coding agent should not be able to move from untrusted content to privileged material without an explicit, observable control point. Resources like AI Coding Agents Security Guide and Guide to the Secret Sprawl Challenge are useful because they focus on the exact failure mode here, secrets in context and over-scoped execution.
Once secrets are in reach, the failure broadens. The agent may not need to “steal” anything in a traditional sense, because the environment has already made the material available. API keys, cloud tokens, private source code, internal messages, and deployment credentials can all be exposed through logs, tool output, generated diffs, or downstream API calls. A well-placed malicious instruction can therefore turn a review task into a data exfiltration path.
What Good Isolation Looks Like for Agent Workloads
The right control is not to ban automation, but to make authority explicit and narrow. The safest pattern is to separate untrusted input handling from any environment that contains live secrets, then provide only the minimum credentials needed for the specific action being performed. In practice, that means sandboxed execution, short-lived tokens, tight repository scoping, and no reuse of privileged sessions across unrelated tasks.
NHIMG’s AI coding agents security guidance aligns with that approach, and the same idea shows up in API Key Management Guide, where scoped issuance and revocation matter more than simply having a key vault. If the agent does not need live production access, it should not be running where production secrets are mounted.
For review workflows, this usually means treating support tickets and pull requests as untrusted until proven otherwise, scanning them before any agent processes them, and keeping secret-bearing contexts out of the same process, container, or workstation session. If the agent must act on code, the action should happen in an isolated workspace with separate credentials, separate network reach, and a predictable audit trail.
Risk and Threat Considerations
The main risk is not just accidental leakage. An attacker can deliberately place instructions, payloads, or references into a ticket or pull request so the agent executes them inside a trusted session. If the session can reach secrets or deployment systems, the attacker gains a path from ordinary collaboration content to privileged execution and exfiltration.
Failure mechanism: The agent conflates untrusted content with legitimate work, then uses inherited access to read files, call tools, or expose credentials that should never have been available to that input.
Impact: A single compromised ticket or PR can expand into secret theft, source disclosure, unauthorized changes, account abuse, or downstream compromise of connected services.
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 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Live secrets in agent context can be exposed by untrusted input processing. |
| NHI-06 — Insecure Cloud Deployment Configurations | Shared execution with live secrets is a deployment isolation failure. | |
| NHI-07 — Long-Lived Secrets | Blast radius grows when agents inherit durable credentials in shared runtimes. | |
| Recommendation — Isolate secret-bearing agent runs and limit token scope before processing untrusted tickets or PRs. Separate untrusted agent execution from production secret environments and enforce sandboxing. Replace long-lived credentials with short-lived, narrowly scoped access for agent workflows. | ||
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Untrusted content can steer an agent into unsafe tool or command use. |
| ASI03 — Identity & Privilege Abuse | Ambient credentials let attacker-controlled input inherit excess authority. | |
| ASI05 — Unexpected Code Execution | Malicious tickets or PRs can trigger code execution inside a trusted session. | |
| Recommendation — Constrain tool access so agent actions require explicit approval or bounded execution. Bind agent permissions to least privilege and separate identities per task or environment. Run agent-assisted code handling in isolated sandboxes with no access to live secrets. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | The issue is overbroad authority in the agent runtime. |
| IA-5 — Authenticator Management | Secret rotation and lifecycle control are central when credentials may be exposed. | |
| Recommendation — Limit each agent session to the minimum access required for the current task. Rotate and revoke credentials quickly when an agent may have been exposed to hostile content. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | Never trust untrusted tickets or PRs just because they enter a privileged workflow. |
| Recommendation — Treat each agent action as a separate trust decision and verify access before execution. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The failure is uncontrolled access to secrets and systems in the agent path. |
| Recommendation — Reduce and review agent access regularly, especially for secret-bearing environments. | ||
Practitioner Guidance
What to prioritise: Separate the trust boundary first. If untrusted tickets or PRs can influence an agent that also sees live secrets, treat that as a design defect, not a tuning issue. The most important control is to prevent secret-bearing sessions from processing hostile input in the same execution path.
What to verify: Confirm that agent runs have no ambient access to production credentials, long-lived tokens, or broad repository scopes. Check whether the agent can reach secrets through environment variables, mounted files, cached shells, shared containers, or inherited developer logins.
Common mistake: Teams often harden prompts but leave execution unchanged. Prompt filtering helps, but it does not solve the core problem if the agent can still run code, inspect private data, or invoke tools with live authority.
Practitioner takeaway: The safest coding agent is the one that can process untrusted content without ever sharing a runtime with secrets it could misuse.
Related resources from NHI Mgmt Group
- What breaks when a workflow engine can execute untrusted code inside the same environment that stores secrets?
- What breaks when AI code review tools are allowed to analyse untrusted pull requests?
- What breaks when a CI/CD workflow can access secrets from untrusted pull requests?
- What breaks when AI coding agents are allowed to run Git operations on untrusted repositories?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
