Governing AI agents in an enterprise is fundamentally an identity and policy problem. You have many teams, many agents, and many downstream systems — and you need to know exactly who authorized what, under which rules, and whether those rules were actually enforced. The controls that hold this together are the same ones that hold user access management together: strong identity, role-based access, delegated administration, and a single place to set and audit policy. If you are still deciding whether to build or buy the governance layer, AI Agent Governance: Build vs Buy provides a structured framework for that decision.
Why enterprise scale changes the problem
A single team running a handful of agents can get by with shared API keys and informal agreements about what agents may touch. That approach breaks the moment a second team joins, or a third. Shared credentials make attribution impossible. Informal agreements produce no audit trail. And when something goes wrong — an agent writes to the wrong database, a cost spike appears, a request reaches a system it should not — you cannot reconstruct who authorized the action or why.
Enterprises also face a structural tension: central security teams want visibility and control; product and AI teams want autonomy to move fast. Governance infrastructure that only supports one of those goals fails both. The architecture needs to enable delegation — giving teams the authority they need — while maintaining central visibility and policy.
Identity as the foundation
Everything else depends on identity being solved correctly. That means every agent, every user, and every application in the system has a distinct, verifiable identity — not a shared credential. It also means those identities are tied to your existing directory: employees authenticate through your SSO provider, and provisioning and deprovisioning flow through SCIM so that day-one access and day-one-hundred deprovisioning happen without manual steps.
For agents specifically, identity needs to be first-class. An agent is not a user, but it acts on behalf of users and organizations, and its actions need to be attributable. Giving agents their own credentials — scoped, rotatable, and revocable independently of any human account — is the prerequisite for meaningful audit logs and for enforcing least privilege. See How to Give an AI Agent Its Own Identity for the practical mechanics of this.
Custom roles and the limits of built-in role sets
Most platforms ship a fixed set of built-in roles: owner, admin, member, viewer. That works for small organizations. Enterprises have functional distinctions that do not map cleanly onto those buckets. A compliance analyst needs read access to audit logs but no ability to modify agents. An AI platform team needs to register new agent connections but should not be able to change billing settings. A support tier needs to handle helpdesk requests without touching governance configuration.
Custom roles solve this by letting you define granular permission bundles that reflect how your organization actually works. You compose a role from the specific capabilities it needs — read agent activity, manage workflows, view cost reports — without granting everything that comes with a broader built-in role. The result is a permission model that enforces least privilege structurally, rather than relying on individuals to avoid features they technically have access to. For a deeper comparison of role models, see RBAC and Custom Roles for AI Operations.
The discipline required here is that role definitions themselves need governance. Whoever can create a custom role that bundles high-impact permissions is effectively a security administrator, even if they are not labeled as one. The assignment authority — who can create roles and assign them — should sit at the organization-owner level, with that fact reflected in your access review process.
Delegated administration across teams
Central administration does not scale to dozens of teams. The model that works is one-level delegation: a central security or platform team defines the boundaries (which features are available, which agents are registered, which MCP servers are connected), and team administrators manage membership and role assignments within those boundaries.
This requires the platform to have a clear distinction between organizational-level settings and team-level settings. Organizational-level settings — SSO configuration, security policy, billing, audit retention, agent registration — stay with the people accountable for the overall posture. Team-level settings — who is on the team, which roles they hold, which workflows they run — can be managed by a team lead without giving them access to the broader organization's configuration.
The practical consequence is that your governance model needs to document which tier each capability belongs to. When a team lead asks "can I add someone with access to agent logs?", the answer should come from a clear policy, not from trial and error in the UI.
Centralized policy, distributed enforcement
The controls that matter most in an enterprise context — content guardrails, spend budgets, data handling rules — need to be set once and enforced everywhere, not configured per-team and hoped to be consistent. A team that opts out of PII redaction because they found it inconvenient is a liability for the whole organization.
The right architecture treats policy as a platform-level concern. Guardrails, budget caps, and audit requirements are configured centrally and applied to all agents regardless of which team owns them. Teams can work within those parameters but cannot override them. This is the same principle as network egress rules: individual services cannot grant themselves network access that the platform has blocked.
For compliance purposes, this matters for a specific reason: auditors and regulators want to see that controls are structural, not discretionary. A policy that can be turned off by a team administrator does not demonstrate the same level of control as one enforced at the platform level.
Audit trails that survive the teams that created them
Enterprise governance requires audit trails that outlast the individuals and teams that ran the agents. When a team is reorganized, or an employee leaves, or an incident investigation begins six months after the fact, the audit record needs to be intact and attributable.
That means audit logs need to be append-only, scoped to the organization rather than to individual users, and retained on a schedule that reflects your regulatory obligations rather than storage costs. The identity attributed in each log entry — which user, which agent, under which role — needs to be stable even after the user or role is modified.
Access to audit logs also needs to be governed. The logs themselves are sensitive: they reveal what your agents are doing, which external systems they touch, and what data they handle. Read access to audit data should require explicit authorization, separate from general agent-management permissions.
Connecting governance to your existing security stack
Enterprises rarely start from scratch on governance. You have an IdP, an SSO configuration, probably a SIEM, possibly a PAM system. Agent governance infrastructure should connect to these rather than run parallel to them.
SSO integration means that agents and the humans managing them are authenticated through the same identity layer your security team already monitors. SCIM provisioning means your HR system or IAM platform drives access, and you do not accumulate stale accounts. Audit logs structured in a standard format — and exportable to your SIEM — mean that agent activity appears in the same dashboards as the rest of your infrastructure, rather than in a siloed console that nobody checks.
This is one of the concrete arguments for a platform approach over custom-built governance: integrations with enterprise identity infrastructure are non-trivial to build and maintain. The IdP landscape changes, SCIM edge cases accumulate, and MFA enforcement needs to stay synchronized with your broader policy as it evolves.
Praesidia is built around this integration surface — SSO, SCIM, MFA, custom RBAC, and audit log export — as first-class concerns rather than add-ons. The goal is that your existing security operations team can monitor agent activity through the tools they already use, without adopting a separate operational model for AI. You can explore the identity and access features in the platform documentation or run through a structured assessment at the self-assessment.
Common questions
What is the difference between a built-in role and a custom role? Built-in roles are fixed bundles shipped with the platform — typically covering the most common access patterns like owner, administrator, and member. Custom roles let you compose your own bundles from individual permission grants, allowing you to match your organization's functional structure precisely. Built-in roles handle the common cases; custom roles handle the exceptions that become the norm at enterprise scale.
How do you prevent privilege escalation through custom role creation? The key control is restricting who can create and assign custom roles. If only organization owners can define and assign roles, then creating a highly privileged custom role does not let a lower-privileged user elevate themselves — they cannot assign it to their own account. The assignment gate is the critical backstop. Periodic access reviews that examine which users hold custom roles with high-impact permissions add a second layer of control.
How should enterprise teams handle agent offboarding when a project ends? Agent identities should be treated like employee accounts: revoked when they are no longer needed. Because agents use their own credentials — not shared team keys — revoking an agent's access is a clean, targeted action that does not affect other agents or the team members who managed it. The audit trail from that agent's activity remains intact after the agent itself is deprovisioned.