A coding agent can produce a correct patch while exposing repository data through a tool call. Reviewing the diff would miss that failure. Agentic AI security therefore starts with the boundaries around what an agent reads, remembers, executes, and sends.
For engineering and security leads deploying coding agents, the useful question is: which component stops an unauthorized action when the model makes the wrong decision?
What Agentic AI Security Covers
AI agent security protects source code, credentials, development environments, persistent context, and release authority throughout an agent’s execution loop. Coding agent security addresses the system producing software; secure coding practices address the resulting code.
This documentation-based analysis draws on the OWASP Top 10 for Agentic Applications and NIST’s Generative AI Profile. The defensive checks below are proposed acceptance criteria, not reported test results.
Map the Coding Agent Trust Boundaries
Prompts, Repository Context, and Memory
Separate authorized task instructions from material supplied to complete the task. Issue descriptions, repository files, retrieved pages, and tool responses can contain attacker-controlled content. A file stored inside your repository does not automatically deserve instruction-level authority.
Memory adds persistence: an incorrect instruction saved during one task can influence another. Record each memory item’s source, project scope, owner, and expiry; require review before promoting retrieved material into durable instructions.
Tools, Credentials, Networks, and Outputs
Map the complete path: developer → agent runtime → MCP server or shell → downstream service. At each hop, identify the acting identity, readable assets, allowed writes, and destinations.
Include subprocesses, package installers, local caches, logs, and generated artifacts. A Git worktree separates working files but does not itself restrict credentials or network access. Outputs cross boundaries too: a patch, CI artifact, or PR comment may expose data or induce another system to act.
The Main Threat Paths
Prompt Injection and Context Poisoning
Prompt injection attempts to turn untrusted content into instructions that redirect the agent. Context poisoning contaminates the material used for later decisions, including stored memory. MITRE ATLAS includes LLM prompt injection as AML.T0051, providing a shared vocabulary for threat analysis.
A defensive scenario might place an unauthorized workflow request in a synthetic issue fixture. The expected outcome is that the agent treats it as task data and any forbidden tool action is independently denied. Prompt injection defense must survive a model-level mistake. Delimiters and detection filters help, but cannot grant or revoke execution rights.
Excessive Permissions and Unsafe Tool Use
Broad agent permissions convert a reasoning error into an operational incident. A repository-reading task rarely needs production credentials, unrestricted shell access, or permission to publish packages.
Cursor’s CVE-2025-54136 advisory describes previously approved MCP configurations being modified without renewed approval. It lists affected versions below 1.2.4 and a patched version of 1.3. The remediation requires approval when an MCP server entry changes. The lesson: authorization must remain bound to the configuration actually executed.
Layer Controls Around the Agent
Enforce controls outside the model. Combine restricted identities, filesystem isolation, network policy, tool validation, and approvals tied to specific actions. Anthropic’s sandboxing design combines filesystem and network restrictions; either boundary alone leaves other routes open.
Use a disposable environment and synthetic data to evaluate a proposed deployment:
| Boundary | Enforced control | Required defensive result |
|---|---|---|
| Repository → runtime | Read-only mounts outside approved paths | An out-of-scope write is denied |
| Runtime → network | Approved destinations and scoped credentials | Transfer to an unapproved test endpoint fails |
| Context → memory | Reviewed, project-scoped promotion | Untrusted instructions do not persist as policy |
| Agent → release | Separate release identity and approval | Agent credentials cannot publish directly |
Assign each row an owner and retain the observed result before expanding access. Set execution timeouts and retry budgets so failures cannot grow into unbounded runs. A policy written only in the system prompt does not satisfy the control column.
For MCP security, validate arguments and authorization at the server, minimize scopes, and reject token passthrough. The MCP security guidance prohibits accepting and forwarding tokens intended for another service. Prefer narrow tools over a general shell where the task permits it; bind sensitive approvals to the destination, payload, and current configuration.
Monitor, Review, and Respond to Incidents
Capture a run ID, repository revision, model and tool versions, policy decisions, approval records, destinations, and resulting changes. Minimize sensitive payloads and protect logs from agent modification. Track denied calls, unexpected destinations, changed tool definitions, repeated retries, and unusual resource consumption.
If suspicious activity occurs, stop the run and queued work, revoke affected credentials, isolate the environment, and preserve relevant evidence. Inspect downstream writes and persistent memory before restarting. Rebuild from trusted state, then repeat the failed boundary check. A clean patch does not clear an unsafe session.
Residual Risks and Human Responsibility
Approved services can still receive inappropriate data; trusted tools can be compromised; reviewers can approve the wrong action. Sandboxes also depend on correct configuration and implementation. Human owners must accept residual risk and decide when repository access, external transmission, or release authority is justified.
This article is not legal or compliance advice. Legal holds, session retention, and secret handling require publication-time verification against applicable law, organizational policy, and current vendor terms.
FAQ
Can Agent Sessions Be Preserved for Legal Hold Without Keeping Secrets?
Not always. Prevent secret collection beforehand where feasible. Once preservation duties apply, do not assume redacted copies can replace originals: US Federal Rule 37(e) addresses loss of electronically stored information, and other jurisdictions differ. Counsel should define preservation scope and permitted redaction. Restrict access to required originals, maintain custody records, and revoke exposed credentials without destroying required evidence.
What Evidence Is Needed Before Trusting an MCP Server?
Require an identified operator, reviewed source or assurance evidence, a pinned package or image digest, dependency inventory, authentication design, permission scopes, data destinations, retention terms, and vulnerability-response ownership. Test these claims in isolation. Registry presence and a reassuring tool description do not establish that the deployed implementation matches your approved configuration.
Can a Revoked MCP Tool Remain Available in a Cached Agent Session?
Its definition may remain visible in cached context; successful execution depends on authorization enforcement. MCP supports tool-list change notifications, but notification is not revocation. Reject calls at the server or policy gateway, invalidate affected credentials, and refresh clients. Verify that an already-open session cannot execute the removed capability.
How Do Third-Party Model Retention Policies Affect Coding-Agent Risk?
They determine where submitted code can persist beyond your runtime. Check the actual account, model route, gateway, feedback channel, and subprocessors. As checked September 20, 2026, Claude Code distinguishes training choices, service retention, feedback uploads, and local transcripts. “Not used for training” does not mean “not retained.” Recheck contractual exceptions and deletion behavior before sending sensitive repositories.
Can Signed Tool Manifests Reduce Agent Supply-Chain Risk?
Yes, when verification checks the expected signer and binds approved metadata to the deployed artifact. Artifact signatures establish origin and integrity; they do not establish safe behavior. Reject unexpected changes, prevent rollback to disallowed versions, and maintain signer-revocation procedures. A signed manifest alone cannot prove that a remote server still runs the reviewed code.
Conclusion
Agentic AI security becomes credible when an unauthorized action fails despite the agent choosing it. The deployment decision rests on demonstrated enforcement at each boundary—and a named owner for the risk that remains.
