The Agent’s Permissions Are the Security Boundary

Originally published on LinkedIn on September 3, 2026. Republished here for the HapDo archive.

An agent’s permissions are its security boundary.

I’m coming at AI, AppSec, and secure coding from a fresh perspective. The question that caught me when I first dove in was where trust sits in this picture. Whom can we trust in an agentic world, and how do we earn that trust?

An agent inherits the developer’s reach

Think about what happens when an agent is wrong. We often extend the privileges of the developer running an agent to the agent itself. The consequences of a misaligned or confused agent can be catastrophic.

We are already seeing what this can look like. Agents have removed databases or pushed changes to production, not maliciously, but because they misinterpreted instructions. During a cybersecurity evaluation, OpenAI models circumvented their containment and compromised Hugging Face systems while pursuing a narrow testing goal.

The model is only one part of the risk. An agent’s identity, credentials, tools, network routes, workspace, and execution policy combine to form a real control plane. Each part of the harness offers a place to constrain the agent, observe what it is doing, and record the requests it makes. Visibility across all of these properties is essential.

Familiar security principles still apply

Agents are not so different from humans when it comes to the security principles we must apply to their environments. Least privilege, distinct identity, authorization, isolation, and auditability still matter.

In some ways, applying those principles becomes easier in an agentic system. An agent does not experience comprehensive monitoring as a privacy violation. We can record its actions, tool calls, and authorization decisions in a way that would be unacceptable if applied to every keystroke made by a person.

That makes evidence a practical control. We should be able to reconstruct what an agent was asked to do, what authority it received, which actions it attempted, which actions succeeded, and why the system allowed or denied each one.

Velocity makes broad permissions dangerous

Broad permissions are a danger zone because agents move much faster than humans. That velocity can turn a small problem into a large one in seconds. It can also mask a mistake that repeats rapidly and consistently.

This is why agent security cannot depend on good intentions or a well-written prompt. Goal orientation supplies direction, but the surrounding system must enforce the boundary. Bake core security principles into what you are building today, before agents learn to consume over-privileged software at scale.

Traceability requires two identities

We need traceability for both the person requesting the work and the agent performing it. A developer or another team member initiates the task; a distinct agent identity carries it out. A trusted system must authorize the requests made by both.

That requires a real identity for everything operating inside the system. If a human and an agent share one indistinguishable identity, we cannot reliably attribute an action, limit the agent independently, or explain what happened afterward.

Humans still own the result

The human must remain at the center of the system. Agent velocity may accelerate our ability to design and code features, but people still own quality control and the consequences of delivery.

That control will change over time. We talk about a human in the loop, on the loop, or out of the loop. The right position will vary with the risk and the evidence available. What cannot disappear is clear human accountability for the outcome.

The security boundary is not the agent’s promise to behave. It is the authority the system gives the agent—and the evidence that proves how it used it.