How should teams prevent coding agents from turning untrusted text into destructive actions?

Place authorization at the tool boundary, not in the prompt. Every issue, PR comment, README, dependency, and hidden instruction should be treated as untrusted input. The agent may still reason over it, but deletes, pushes, API calls, and credential reads must require runtime policy decisions that the agent cannot bypass by following the text it just read.

Why This Matters for Security Teams

Coding agents are not just reading text, they are converting untrusted text into executable intent. A README, issue thread, dependency note, or hidden instruction can steer the agent toward deletes, pushes, secret reads, or API calls if authorization lives in the prompt instead of at the tool boundary. That is why this is an execution-control problem, not a prompt-quality problem. Current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both point toward runtime governance because agent behaviour is dynamic and context dependent.

NHIMG research shows the same pattern outside the lab: in the Replit AI Tool Database Deletion incident, tool access turned a text-driven workflow into a destructive action. The practical lesson is simple: any place the agent can call a tool is a place where policy must override persuasion. In practice, many security teams encounter destructive agent behaviour only after a prompt injection or poisoned context has already executed, rather than through intentional testing.

How It Works in Practice

The safest pattern is to separate reasoning from authority. Let the agent read untrusted content, summarize it, and propose a plan, but require a runtime policy engine to decide whether a tool call is allowed. That policy should evaluate the specific action, target resource, identity, environment, and user intent at the moment of request. This is the practical meaning of intent-based authorisation for agents, and it aligns with current guidance from the CSA MAESTRO agentic AI threat modeling framework and MITRE ATLAS adversarial AI threat matrix.

Operationally, teams should treat every tool as a privilege boundary:

• Require explicit approval for destructive actions such as delete, overwrite, push, revoke, or deploy.
• Use short-lived, task-scoped credentials so the agent cannot reuse access across unrelated steps.
• Bind tool use to workload identity and request context, not to a static prompt instruction.
• Log the input, policy decision, and tool result so suspicious chains can be reviewed later.

This is especially important when the agent can chain tools, read repository content, and then use those findings to justify a higher-risk call. NHIMG’s Analysis of Claude Code Security and OWASP NHI Top 10 both reinforce that the control point must sit where action becomes effect, not where text becomes interpretation. These controls tend to break down when agents are granted broad shell access or CI/CD credentials because one policy gap can be amplified across many tool calls.

Common Variations and Edge Cases

Tighter tool gating often increases developer friction, requiring organisations to balance safety against workflow speed. That tradeoff is real, and best practice is evolving on how much autonomy to allow by default. The current consensus is clear on one point: high-risk actions need stronger runtime checks than low-risk reads, but there is no universal standard for exact thresholds yet.

Edge cases matter. An agent that only drafts pull requests may still become dangerous if it can also read secrets, modify workflow files, or trigger CI jobs. Likewise, retrieval over documentation is not harmless if the retrieved text can contain hidden instructions or social engineering designed to steer tool selection. For that reason, untrusted input controls should cover comments, issues, code review notes, package metadata, and repository files alike. The Gemini AI Breach, Google Calendar Prompt Injection and CoPhish OAuth Token Theft via Copilot Studio show how easily text-driven paths can cross into credential misuse when policy is not enforced at execution time.

Teams should also be careful with exceptions. Emergency access, break-glass permissions, and human override paths are sometimes necessary, but they need tighter monitoring and short expiry windows. If policy can be bypassed by adding the right phrase to a prompt, then the environment is already operating outside safe agentic governance.

Related resources from NHI Mgmt Group

• How should security teams manage permissions for AI agents?
• How should teams govern AI agents that use MCP?
• How should security teams govern AI agents that use OAuth access?
• How should security teams limit the risk from AI agents that have access to production systems?