The Permission Boundary Myth: Why Authorized Doesn't Mean Appropriate for Coding Agents

Coding agent security has a framing problem. Most security conversations around these tools center on the wrong question. 'Did the agent have permission to do that?' is a reasonable place to start, but in the context of autonomous AI systems, it's not where the risk actually lives. In Zenity Labs' research into the coding agent threat model, the pattern that keeps surfacing isn't that agents are doing things they aren't allowed to do. It's that they're doing things they're allowed to do, for entirely the wrong reasons.

The conventional security stack, including endpoint detection and response (EDR), data loss prevention (DLP), and identity and access management (IAM), was built to figure out if what the agent did was permitted. It does that reasonably well. What it can’t determine is whether a coding agent session has been compromised and if the action it took was appropriate.

That's the gap this piece is about.

What Conventional Tools Are Built to See

Every tool in the conventional security stack was designed around a specific threat model.

• EDR watches for malicious process behavior: exploits, injections, and known-bad signatures.
• DLP monitors data movement across file transfer channels.
• IAM tracks which identities have access to which resources and enforces that access policy.

These tools do what they were built to do. The problem is that coding agent attacks don't use the vectors those tools were built to detect.

When a developer's Claude Code session reads a .env file, that's a permitted action. The agent has access to the filesystem. Reading a file within the workspace is entirely within scope. When that same session, minutes later, issues a curl request to an external URL with the contents of that .env file embedded in the request body, that's also a permitted action. The agent is authorized to make network requests. Both events are logged as routine. No threshold is crossed. No signature is matched.

The attack is invisible to every conventional control layer because both of its components are individually authorized. The threat lives in the relationship between them, and that relationship is exactly what conventional tooling has no mechanism to observe.

The Structural Problem with Prompt Injection

Indirect prompt injection, where untrusted content the agent processes during a normal task contains hidden instructions that redirect the agent's behavior, is the primary entry point for coding agent attacks. Zenity surveyed security practitioners on AI agent risk, found that prompt injection ranked as the #1 concern at 29%, ahead of secrets exposure at 24% and data exfiltration at 20%. That ranking reflects practitioners' correct intuition that injection is the root cause of most downstream attacks.

What makes prompt injection a structural problem rather than an implementation flaw is that large language models (LLMs) don't have a reliable mechanism for distinguishing data from instructions. An agent reading a GitHub issue to understand which feature to implement and an agent reading a GitHub issue that contains injected instructions to exfiltrate credentials are, from the model's perspective, doing the same thing: processing content and deriving intent from it.

The attack exploits the model's core capability. There's no patch for it. You can reduce the attack surface through configuration hardening, restricted data sources, and careful Model Context Protocol (MCP) server governance, but the underlying structural vulnerability is a property of how LLMs work, not a misconfiguration you can fix.

This is why detection has to happen at the behavioral layer, not the content layer. You can't reliably inspect every piece of content an agent processes for injected instructions. What you can do is monitor what the agent does after processing that content and flag patterns that are anomalous relative to the agent's declared task.

What Least Privilege Misses

Least privilege is the right starting point for coding agent security. An agent executing a specific debugging task doesn't need access to the financial reporting system, even if the developer's service account technically grants it. Remediating over-permissioned agents is one of the highest-value interventions in any agent security program.

But correctly implemented least privilege still isn't sufficient.

An agent can stay entirely within its authorized permission set and still behave in ways that are inappropriate for its declared purpose. The permission boundary defines the outer limit of what the agent can reach. It doesn't constrain how the agent reasons about what to do within that space, how it sequences its actions, or whether the aggregate effect of its individually permitted actions is consistent with the intent for which it was deployed.

Zenity describes the missing layer as least agency: scoping not just what agents can access, but what autonomous actions they should be permitted to take, in what sequence, under what conditions, and subject to what oversight. It's a different question than least privilege asks.

Least privilege asks: What can this agent access? Is the permission set appropriately scoped? Does the agent hold credentials beyond its task requirements?

Least agency asks: What autonomous actions should this agent take? In what sequence, and under what oversight? Is the aggregate effect of its actions consistent with its declared purpose?

The second set of questions doesn't have an IAM answer. It requires continuous, stateful monitoring of the agent's execution trajectory, something no tool in the conventional security stack provides.

Intent Observability: The Missing Layer

Closing the gap between permitted and appropriate requires a different kind of monitoring than most security teams currently have. Two types of observability are required for coding agent security.

Execution observability (EO) captures what the agent did: tool calls, API invocations, data accesses, and system events.

Intent observability (IO) captures why the agent did it: the reasoning chain, goal state, and decision context.

Most organizations have some version of execution observability, though often at insufficient granularity. Intent observability is rare, and it's precisely what enables you to distinguish an agent operating as intended from an agent operating under an attacker's instructions.

Intent observability means maintaining a stateful model of the agent's execution trajectory, not just logging individual events as they occur, but continuously evaluating whether what the agent is doing is consistent with what it was supposed to do.

• Did the agent's goal shift mid-session in response to content it processed from an external source?
• Did the agent begin accessing data with no relationship to its declared task?
• Did a sequence of individually authorized tool calls collectively produce an outcome that no reasonable reading of the original task would have sanctioned?

Those are the questions that catch coding agent attacks. And they're the questions that authorized/not-authorized framing is structurally incapable of answering.

The regulatory landscape is moving in the same direction. SOC 2 assessments increasingly require evidence that controls apply to automated systems. The EU AI Act imposes audit-trail and human oversight obligations for high-risk AI systems. Auditors are beginning to ask not just 'what permissions did the agent have?' but 'what did the agent actually do, and how do you know it was appropriate?' Organizations that can answer the second question are the ones building on intent observability. The rest will be reconstructing the answer under audit pressure.

The most dangerous assumption in coding agent security isn't that agents will bypass authorization. It's that authorization is sufficient. The attack that's actually happening operates entirely within what's permitted, and the only way to see it is to monitor not what agents can do, but what they're trying to do.

The full threat model, detection patterns, and governance framework are in the eBook → Download The Ultimate Guide to Securing Coding Agents