Agent Governance & PAM

An agent with overly broad permissions can accidentally delete data, initiate payments, or make configuration changes that are hard to undo. Governing agent access is the discipline of designing permissions that prevent that.

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 three questions: What data does this agent need to read? What systems does it need to write to? What actions should it never be able to take, regardless of what it's instructed to do?

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

Finance automation agent

A finance team needed to automate monthly reconciliation: collect transaction data from two banking providers and a payment processor, normalize it, and import it into their accounting platform.

The agent's identity was granted

Read-only API credentials to each financial data source. No payment initiation. No account modification. Read only.
Write access to exactly one endpoint in the accounting software: the transaction import endpoint. Not the payment endpoint. Not account settings. The import endpoint only.
No access to HR systems, infrastructure, or anything outside its defined scope.
Execution on a dedicated host with no network route to internal systems beyond the APIs in its scope.

The agent completes reconciliation in minutes instead of hours. The risk of it accidentally initiating a payment, modifying historical records, or accessing data outside its scope is not mitigated by guidelines — it is structurally impossible given what it was issued.

That's the standard we design to.

A Note on Models

Agent governance principles apply regardless of which model powers the agent. We've implemented agent identity architectures for Claude, ChatGPT, and Gemini deployments. Claude is the model we have the deepest experience with for agentic use cases — Anthropic's work on AI safety and its model's behavior under ambiguous instructions makes it the model we most commonly recommend when agents are taking real-world actions. That said, the identity and permission infrastructure we build is model-agnostic.

Let's Talk

Building AI automation and not sure how to scope permissions safely?

That's the conversation to have before deploying, not after.

Schedule a conversation