Your Agent's Permission Model Is the Real Security Boundary. Your Guardrails Are Decoration.

Tenet Security walked onto the DEF CON 34 main stage and made an AI agent rewrite a company's DNS. The agent read a Cloudflare log, found a prompt-injection payload in a blocked event's User-Agent header, and followed the instruction. Claude Code complied 9 out of 10 times. Nothing malfunctioned. No rule broke. The firewall did its job. The agent did not care.

The detail that should keep you up at night is that the firewall blocking the request is exactly what let the attack in. The block wrote the poisoned header into the log the agent trusts, and the agent read it as innocent request metadata. The agent held two tools in one session, a read tool for analytics and a write tool for DNS, and it used both. Tenet found 48 organizations running the same exposed setup, including six confirmed Fortune 500 companies. The credentials the agent used were issued months earlier and never revoked.

The block rate is not your security boundary. Your guardrails are not your security boundary. Your permission model is.

This is the direct continuation of the argument I made in Note #165, that agent safety lives in the execution boundary, and Note #169, that encrypted attacks bypass plaintext guardrails. The story has moved past whether guardrails can stop prompt injection. They cannot. The question is what the agent is allowed to do when the guardrail fails.

WHY GUARDRAILS FAIL

The Grok encrypted-instruction attack showed that a model will decrypt a hidden command and follow it with no warning. The Copilot ?autorun=1 bypass showed that an AI assistant will reveal its own safety mechanism under interrogation, leaking the parameter that disables user consent. The GhostJacking attack showed that a blocked payload in a log file is enough to make an agent rewrite DNS.

The thread connecting all three is that LLMs cannot reliably distinguish between content from an untrusted source and a legitimate user instruction. Every mitigation so far is a guardrail layered on top of this fundamental flaw. Guardrails are pattern matchers. They catch known attacks. They fail on novel ones, and they fail silently.

Look at how each one failed. Grok did not break a rule. It decrypted a page the user asked it to summarize, and the hidden command was just more text to it. Copilot did not break a rule. It answered a question about its own limits, and the answer was the parameter that disabled consent. GhostJacking did not break a rule. The agent read a log, verified two claims it could check itself, and acted on the rest. In every case the model behaved exactly as it was trained to behave. That is the point. You cannot pattern-match your way out of a model doing what models do.

OWASP ranks prompt injection as the number one threat in AI. The field is moving from academic proof-of-concept to demonstrated breach vector. Real organizations are exposed. The question is not whether your guardrail will be bypassed. It is what happens after.

THE PERMISSION LAYER IS THE BOUNDARY

If the guardrail fails, the only thing standing between the agent and the damage is what the agent is authorized to do. Today, most agents hold broad, persistent credentials. They have access to your DNS, your Slack, your email, your CRM, and your codebase, all with tokens issued months ago and never scoped to a specific task.

This is the problem the Beyond OAuth paper attacks. Instead of granting an agent blanket access to your systems, you authorize specific tasks via natural language descriptions. The system translates those descriptions into fine-grained permission slices. "Read this Cloudflare log and summarize blocked events" does not grant DNS write access. "Update this DNS record" does not grant log read access. Each task gets exactly the permissions it needs and nothing more.

The GhostJacking attack would have stopped at the permission layer. The agent could read the log. It could not rewrite DNS. The credential for DNS writes was never granted for a log-summarization task. The read tool and the write tool would never have shared a session, because no single task would have requested both.

STAGED TRUST AND THE LONG GAME

The permission layer has its own attack surface. TrustShiftProbe shows that attackers can build trust with an agent over multiple interactions before exploiting it. A staged trust attack works because each individual interaction looks benign. The agent gradually accepts the attacker's content as legitimate, and by the time the malicious request arrives, the trust boundary has shifted.

This means the permission model cannot be static. It must be task-scoped and time-limited. Credentials issued for one task should not persist into the next interaction. The Beyond OAuth paper calls this "natural language slices": each task gets its own authorization, and the authorization expires when the task completes.

WebMCP-Phalanx addresses the browser side of this problem. Browser-integrated agents see untrusted web content constantly. The paper enforces trust boundaries that separate trusted agent operations from untrusted web data. Without that boundary, every web page the agent visits is a potential injection vector, and the permission layer is meaningless if the agent cannot tell whose instructions it is following.

THE TASK-SCOPED PERMISSION BOUNDARY

Here is the framework I want you to take from this. Call it the Task-Scoped Permission Boundary. It is a three-layer authorization model for AI agents, and it is the difference between an agent that should not do something and an agent that cannot do something.

Layer 1: Task Definition. The user describes what the agent should do in natural language. "Summarize this log file." "Update this DNS record." "Read this Slack channel." The task definition is the authorization request. It is the only thing the agent is allowed to act on.

Layer 2: Permission Slice. The system translates the task definition into a finite set of permissions. Log summarization gets log read access. DNS update gets DNS write access for a specific record. No task gets permissions it did not request. No permissions persist beyond the task.

Layer 3: Execution Boundary. The agent operates inside the permission slice. If the agent encounters an instruction that requires a permission it does not have, the request fails. Not gracefully. Hard fail. The agent cannot escalate its own permissions. It cannot ask for more access mid-task without user approval.

This is Note #165's execution boundary made concrete. The permission layer is the execution boundary. It is the difference between "the agent should not do this" and "the agent cannot do this." And it is the layer that stops GhostJacking cold, because the agent never holds the write credential it would need to hijack the domain. It also answers the governance question I raised in "Agents Need Governors, Not Gatekeepers": a governor is only as strong as the boundary it enforces, and that boundary is the permission slice, not the prompt filter.

The hard part is that this is an engineering problem, not a policy problem. A permission slice is only as good as the enforcement underneath it. If the runtime lets an agent call a write tool it was not granted, the slice is decoration. If the runtime lets a read tool and a write tool share a session, the slice is decoration. The model does not enforce the boundary. The runtime does. That is why this belongs in the execution layer, not in the prompt, and why Note #170 on memory as an attack surface matters here too. A poisoned memory can carry a request across tasks, so the permission slice has to be re-issued fresh every task, not inherited from whatever the agent remembers.

WHAT TO DO TODAY

1. Audit your agent credentials. List every token, every API key, every OAuth scope your agents hold. If any credential grants broader access than the agent's current task requires, revoke it and reissue scoped.
2. Stop granting persistent credentials to agents. Every agent task should get a time-limited permission slice that expires when the task completes. If your tooling does not support this, build it or find tools that do.
3. Separate read and write paths. The GhostJacking attack worked because the agent could both read logs and write DNS. Those permissions should never coexist in a single credential. Read tasks get read permissions. Write tasks get write permissions. Never both.
4. Test your permission layer against staged trust attacks. TrustShiftProbe shows attackers can build trust over multiple interactions. Your permission model should not grant more access to an agent that has been "behaving well." Trust is not a permission escalator.
5. Define trust boundaries for browser agents. If your agent browses the web, it will encounter prompt injection. WebMCP-Phalanx shows how to separate trusted operations from untrusted content. Implement the boundary before you deploy, not after.

THE UNCOMFORTABLE QUESTION

Claude Code followed a poisoned instruction 9 out of 10 times. Your guardrails are pattern matchers waiting to fail. The only thing that stops the next GhostJacking is what your agent is allowed to do when the guardrail does not catch it. What permissions does your agent hold right now that it does not need for its current task?