Agent governance 101

If you run AI agents — and you do, even the ones you didn’t sanction — you need to govern them. This guide is the starting point: what “agent governance” actually means, why it isn’t the same as the IAM you already have, and the mental model the rest of the Learn series builds on.

What “agent governance” means

Agent governance is the practice of deciding, enforcing, and proving what every AI agent in your organization is allowed to do. It has three obligations:

1. Decide — what can each agent do, and under what conditions?
2. Enforce — make that decision real in the path, before any action runs.
3. Prove — keep an immutable, attributable record of what every agent did.

Notice what’s not on the list: writing a good system prompt. Prompts are instructions to a model; governance is enforcement that doesn’t depend on the model cooperating.

Why agents aren’t just “non-human users”

You might think your existing identity and access management already covers this. It’s a head start, but agents break three assumptions human IAM makes.

• Speed and scale. A human makes a few hundred consequential actions a day. An agent makes thousands an hour, with no coffee break in which a mistake becomes obvious.
• Steerability by untrusted input. A human won’t wire $9,000 to a stranger because an email told them to. An agent can be prompt-injected into exactly that. The text it reads is now part of the attack surface.
• No judgment at the edges. Humans apply common sense to ambiguous situations. Agents apply the policy you gave them — and nothing else. The boundary has to be in the rules, not in the operator’s head.

So agent governance keeps the spirit of IAM (identity, least privilege, audit) and adds enforcement designed for things that act fast, can be tricked, and won’t improvise safely.

The model: scope, guard, log

Three controls cover every action an agent takes. You’ll see this triplet throughout HiveKey and the rest of these guides.

Scope — what can this agent do at all?

Scope is least privilege for agents. Each agent gets a deliberate set of capabilities, defined once as a reusable role. Anything you don’t grant is invisible — not just denied, but absent from the agent’s tool list, so it can’t be called or even discovered.

Guard — should this specific action run, right now?

Guards are your business rules, enforced before the side effect. Spend caps, domain allowlists, approval thresholds, change-freeze blocks. Scope says “this agent can send mail”; guard says “but not to that domain, and not 10,000 of them.”

Log — what actually happened?

Every action, allowed or denied, is written to one immutable trail that traces back to the human who owns the agent. Recorded in the path as it happens — not reconstructed later.

If you remember one thing: scope is what’s possible, guard is what’s allowed, log is what happened. Every governance question maps to one of those three.

A quick self-assessment

Ask these about your current setup. Each “no” is a gap this series will help you close.

• Can you list every agent running against your systems, and who owns each one?
• Does any agent hold a raw API key with more power than its job needs?
• If an agent were prompt-injected right now, what’s the worst action it could take?
• Could you produce an immutable record of everything one agent did last month?
• Can you revoke an agent’s access across every tool in one action?

Where to go next

This was the map. The rest of the territory:

• Least privilege for AI agents — how to scope an agent down to exactly its job.
• Setting spend caps & approval thresholds — your first and most valuable guards.
• Streaming agent audit logs to your SIEM — making the trail useful where you already work.
• SOC 2 readiness for AI agents — turning all of the above into evidence an auditor accepts.

Govern agents like you govern employees: provisioned through SSO, scoped by role, guarded by policy, audited centrally, and revocable in one click. Everything else is detail.