AI agents are the first software that decides what to do next — which makes them the first software that needs governance, not just configuration. A script does what it was written to do. An agent interprets instructions, chooses actions, calls tools, and touches data on its own initiative. Enterprises are deploying thousands of them. Most are doing it with the identity model of a cron job.
This article covers the governance model that holds up: identity, permissions, delegation, and audit — designed for fleets, not pets.
The problem: agents inherit god-mode by default
The typical first agent deployment looks like this: a team creates a service account, attaches an API key with broad access ("we'll tighten it later"), and wires the agent to email, the CRM, and a database. It works in the demo. Then reality arrives:
- The key leaks — and the finder holds everything the agent could touch.
- A prompt injection lands — and the attacker doesn't get "access to an agent," they get access to everything the agent can reach. (See: Prompt Injection Attacks: How They Work and How to Stop Them.)
- The auditor asks who deleted the record — and the answer is "the shared key used by eleven agents and two engineers."
- One agent misbehaves — and revoking its key breaks ten others.
None of these are model failures. They are identity failures — the same failures that made shared admin passwords a fireable offense in traditional IT, replayed at machine speed.
The four pillars of agent governance
1. One agent, one identity
Every agent gets its own identity — not a shared service account, not a borrowed user login. This single change makes everything else possible: attribution ("agent collections-caller-014 did this"), isolation (its compromise is not everyone's compromise), and lifecycle management (created, rotated, retired like any principal).
2. Least-privilege permissions
Scope each agent to the minimum tools and data its job requires:
| Agent | Needs | Does NOT need |
|---|---|---|
| Appointment booker | Calendar write, customer name lookup | Payment records, email send |
| Support triage | Ticket read/write, KB search | CRM export, user admin |
| Collections caller | Account balance read, call API | Balance write, full account history |
The design question is always blast radius: if this agent were fully hijacked today, what could it reach? If the answer is uncomfortable, the permissions are wrong — before any attack happens.
3. Delegation, not impersonation
Agents usually act for someone — a user, a team, a workflow. Impersonation (the agent simply becomes the user) destroys attribution and inherits every permission the user has. Delegation is the correct primitive: the agent holds its own identity plus a scoped, time-bounded grant to act on the user's behalf, bounded by the intersection of what the user may do and what the agent may do. When either party's rights shrink, the grant shrinks with them.
4. Instant, surgical revocation
When an agent misbehaves — bad deploy, poisoned instructions, compromised dependency — you need to shut off that agent in seconds without collateral damage. That requires centralized, short-lived credentials: tokens that expire quickly and are checked against live policy, so revocation takes effect on the next request, not at the next quarterly key rotation.
Governing at fleet scale
Per-agent configuration stops working somewhere around agent number twenty. Governance that scales attaches policy to roles and templates, not individuals:
- Roles — "outbound-caller," "document-processor," "triage-agent" — each carrying a permission set, security policy, and monitoring profile. New agents are stamped from the role.
- Environment boundaries — development agents physically cannot reach production data; promotion is an explicit, logged act.
- Expiry by default — agents and their grants have TTLs. Fleets accumulate abandoned agents the way clouds accumulate zombie VMs, and each one is unmonitored attack surface.
- Anomaly detection — a fleet's behavior is legible in aggregate: an agent that suddenly calls a tool it never used, at triple its normal volume, at 3 a.m., should page someone. This is where identity data and observability converge.
This is also what makes an agent marketplace viable: you can only safely deploy third-party agents — as with Net3 Marketplace — when every one of them arrives inside an identity envelope you control, inheriting your policies rather than bringing its own.
Audit: the four-question test
For every consequential agent action, your logs should answer:
- Which agent performed it (unique identity, version)?
- On whose behalf (delegation chain back to a human or system)?
- Under what permission (the specific grant that authorized it)?
- With what outcome (what changed, what was returned)?
If any of the four is unanswerable, you have a governance gap — one that regulators in banking, insurance, and healthcare are already learning to probe. Immutable, attributable logs are the difference between an incident report and an existential audit finding. Net3 Monitor records these trails as a native output of the platform.
Where this lives in the stack
Agent governance isn't a product you bolt on; it's a property of the platform your agents run through. On Net3, Identity issues and verifies agent identities and delegated grants, Shield enforces policy on every prompt and action, Gateway is the choke point every request crosses, and Monitor keeps the evidence. One control plane — which is precisely what makes one policy enforceable across a thousand agents.
The bottom line
The enterprises winning with AI agents aren't the ones with the most agents — they're the ones that can answer, at any moment, what is this agent, what can it do, who is it acting for, and how do I stop it? Treat agents as first-class identities from day one. Retrofitting identity onto a thousand-agent fleet is a migration; designing it in is a decision.