Agent Governance & PAM
Decide what an agent may do before it starts doing it. A useful agent needs clear boundaries: what it can access, which actions it can take, and where a person must review the work. Those decisions belong in the system’s permissions and operating controls, not only in its instructions.
The Problem
The blast radius problem.
When a human makes a mistake, the damage is bounded by what they had access to. The same is true for agents — but agents operate faster, at higher volume, and without the hesitation that sometimes stops a human from clicking confirm.
Broad permissions amplify mistakes. An agent with write access to your entire infrastructure can accidentally modify it. An agent with write access to exactly one import endpoint in your accounting software can do exactly one thing: import. That constraint isn't a limitation — it's the design.
The same least-privilege principles that govern human Privileged Access Management apply to agents. What's different is that most organizations have never had to think about identity architecture for non-human actors. We have.
Our Approach
How we approach it
Purpose-built agent identities
Each agent gets its own identity — a dedicated service account or managed identity in your directory, separate from human accounts, with its own authentication credentials, access controls, and audit trail. When something goes wrong, you know immediately which agent acted and what it had access to.
This matters more than it sounds. An agent authenticating as a human's account inherits that human's full permission set and produces no distinguishable audit record. An agent with its own identity is traceable, revocable, and scoped. We provision these identities in JumpCloud, Microsoft Entra ID, Okta, or whichever directory you run.
Permissions designed from the task outward
We start with five questions. What may this agent read? What may it change? Which of its actions need a person's review before they take effect? Where are those limits enforced? And who can inspect what it did, or stop it?
The answers define the permission set, which is enforced at the identity and API level — not just in the agent's system prompt. A permission that doesn't exist in the API layer cannot be exercised by any model, no matter how it's prompted. That's a meaningful security guarantee that prompt-level guardrails alone cannot provide.
Write access minimization
Read access is granted broadly where needed. Write access is granted narrowly and specifically. For most automation tasks, an agent that reads from ten systems and writes to one is safer, more auditable, and easier to reason about than one with broad write access and good intentions.
In Practice
How we govern our own agent
support.agent works our own ticket queue every 30 minutes, investigating network problems, security events, and support requests across the platforms we manage for clients. It is the clearest example of these principles in daily use.
What support.agent is granted
Its own account in our directory, separate from any person’s login. Group memberships decide which connections it can reach, and revoking one group closes that door.
Read-only connections to client platforms. The connections it uses to answer questions are built so that a tool that changes a system cannot be added to them. Where a platform’s connection can make changes, that ability sits behind a separate permission the agent does not hold.
Write access only to internal places: a note on the ticket, a message in Slack, a file in Drive, and its own working records.
Every call logged under its own name, with the tool, the arguments, the client it touched, and the outcome, so its activity can be reviewed separately from any person’s.
What it produces is a finding. A Team Member decides what happens next and makes any change, with the evidence already in hand.
The same approach applies to an agent that has to write. A reconciliation agent for a finance team, for example, would get read-only credentials to its banking and payment sources and write access to a single import endpoint in the accounting platform, and nothing else. The credentials it holds cannot initiate a payment or modify a historical record, and the one write it performs is logged for a person to review.
That's the standard we design to.
A Note on Models
These principles apply whatever model powers the agent. We have built agent identities for Claude, ChatGPT, and Gemini deployments, and the identity and permission infrastructure is the same for each.
Govern Your Agents
Ready to put guardrails on your AI agents?
Let's map out what access your agents actually need, and lock down everything else. We'll walk through your current setup and where the gaps are.
Let's TalkRelated
New to AI agents? Start with the fundamentals.
See what disciplined agent access looks like in practice.