How to govern AI agents: Identity, access, and control at enterprise scale

Much of the discussion around AI risk still focuses on prompts, hallucinations, and model behavior. Yet many of the emerging risks associated with AI agents involve tool misuse, identity and privilege abuse, excessive autonomy, approval bypasses, and unauthorized access to enterprise systems. These are among the risks highlighted in OWASP's guidance on agentic AI.

As organizations deploy more agents, the challenge is no longer just what a model knows. It is what an agent is allowed to do, who approved those permissions, and how those decisions are governed. An agent cannot misuse a tool it cannot access, spend money it cannot reach, or retrieve data it was never authorized to see. Governance starts long before a model generates a response.

Why is the fuse shorter?

A stale service account usually sits there doing nothing until somebody exploits it. An agent is built to act. It calls tools, writes to systems of record, spends money continuously from the day it is switched on. Dormancy was doing a lot of quiet work in our old risk models, and it is gone.

The conversation has shifted from model accuracy to accountability. What is the agent allowed to do? Who authorized those permissions? And is there evidence to support those decisions?

What does this look like in practice?

A finance team builds an invoice-processing agent. It needs access to systems, so a ticket is raised and credentials are issued. Governance often ends there. No ownership record, no access review, no audit trail. Yet the agent can now interact with any model, budget, or tool its permissions allow, including ones nobody considered when that access was approved.

Within months, organizations can accumulate dozens of agents built by different teams on different platforms. At that point, answering basic governance questions becomes surprisingly difficult. Which agents can initiate payments? Which can access sensitive data? Who approved that access? If finding those answers requires a manual investigation, the problem is not a tooling gap. It is the absence of a centralized register.

This is not a rogue-agent story. It is ordinary delivery under normal time pressure, which is precisely why it reproduces so reliably across teams and companies. Any control that depends on every engineer remembering to ask permission is not exactly a control. 

What does governing an AI agent actually require?

Before deciding on a particular platform or architecture, it helps to step back and ask a broader question: what does governing an AI agent require?

An AI agent is not just a model. It is an operational identity with access to enterprise systems, data, tools, and budgets. Like any other enterprise identity, it must be governed throughout its lifecycle, from registration and approval through runtime execution and eventual retirement.

Governance must establish:

• Who owns the agent

• What it is allowed to access

• Which models and tools can it use

• What data can it consume or disclose

• How much compute or token budget it can consume

• Which actions require additional authorization or human approval

At runtime, these controls cannot be purely static. A request may be permitted for one agent, user, dataset, environment, or risk level and denied for another based on the context.

Consider a customer support agent with access to a CRM, ticketing platform, and payment system. Retrieving a customer's address to resolve a support ticket may be entirely appropriate. Accessing that customer's payment details or financial records may not be. If an agent accesses customer data outside its approved scope, the result could be a reportable privacy incident rather than a simple policy violation. Effective governance therefore requires evaluating not just who the agent is, but what it is trying to do, what data it is accessing, and whether that action is appropriate in the current context.

Effective governance therefore requires continuous evaluation of identity, intent, data sensitivity, model selection, tool access, action scope, risk, cost, and execution context before allowing an operation to proceed.

The five control areas of AI agent governance

At a high level, agent governance can be viewed across five control areas:

• Identity & lifecycle: Register agents, establish ownership, authenticate them, assign risk classifications, and manage their lifecycle.

• Access & authorization: Define which models, tools, APIs, data sources, and actions an agent can access.

• Runtime policy enforcement: Evaluate requests dynamically based on identity, context, data classification, risk, environment, cost, and business policy.

• Human oversight & accountability: Require approval for high-impact actions and maintain traceability of decisions and executions.

• Continuous monitoring & assurance: Capture telemetry, audit policy decisions, measure consumption, and periodically reassess agent permissions and risk.

Agent governance cannot be implemented through a single control or gateway. It requires identity, policy, security, data protection, runtime enforcement, observability, and operational controls working together. 

How to enforce AI agent governance?

With these requirements established, the next question is not “Which product should we deploy?” but rather: “How can we assemble these capabilities into an enterprise control model while maximizing the security investments we already have?”

We observed similar problems while working with several clients and built an agent control plane: a governance layer that sits between the agents and the model and tool gateways.

Nagarro’s Agent Control Plane

It implements these governance principles, designed to integrate existing enterprise security capabilities and introduce AI-specific controls where gaps exist.

Every model invocation and every tool call passes through the Agent Control Plane, resolving a fundamental question before execution: which agent is this, what is it attempting to do, and is it authorized to do so under the current context and policy?

That decision covers far more than simply allowing or denying an action. It determines:

• Which models an agent may invoke

• What data it is permitted to send to an LLM

• Which tools and APIs it can access

• What data it can retrieve or disclose 

• How much compute or token budget it can consume

• Whether the action requires human approval and is appropriate for the agent's role, risk level, and operating context.

It is built on a foundation of identity authorization, policy, and approval machinery recognized by IAM practitioners, empowered by an AI agent. 

Much of the foundation for governing AI agents already exists in identity and access management. The same concepts used for users, applications, and service accounts, such as identities, permissions, policies, and approvals, can also apply to AI agents. The challenge is not creating new authentication methods. It is ensuring that existing security controls remain effective when agents can independently choose what systems to access, what data to use, and what actions to take. This autonomy introduces new requirements for enforcement, oversight, and accountability.

• Establish a trusted inventory of AI agents:
  You need a central system that keeps track of all AI agents. But simply maintaining a list isn't enough. The system that registers an agent should also be the only way that agent gets credentials and access to enterprise systems.

• Introduce human oversight before deployment:
  Registering an AI agent is only the first step. Registration does not automatically give the agent access to anything. A designated human must review the requested permissions and explicitly approve them before issuing credentials.

• Apply policies at the group level, not the individual agent level:
  Managing permissions and controls for each agent individually becomes impractical as the number of agents grows. Instead, organizations should define policies based on business function or use case. For example, all agents within a business unit could be assigned the same model, spending limits, content controls, and approval requirements. These policies should be centrally managed, version-controlled, and subject to the same review and approval processes used for other enterprise changes. Before updating a policy, reviewers should be able to see which agents will be affected.

• Discover and govern unmanaged agents:
  No governance process is perfect. Teams will inevitably create AI agents outside approved workflows. When an unregistered agent attempts to access enterprise systems, it should be blocked and automatically recorded for review. Capturing details about the attempted access allows security and governance teams to investigate the agent and determine whether to onboard it through the proper process. Blocking access alone is often ineffective. It encourages users to find workarounds and can lead to the growth of unmanaged or "shadow" AI. A better approach is to treat these events as both a security control and an intake mechanism, helping organizations identify and govern agents that would otherwise remain invisible.

• Maintain audit evidence for every decision:
  Organizations need a complete audit trail for AI agents, including approvals, policy decisions, credential issuance, access changes, and enforcement actions. Each decision should be linked to the agent's approved scope, applicable policies, and the individuals responsible for approving it. Just as important are the actions that were prevented. If a control blocks an agent from accessing a system, using a tool, or performing an unauthorized action, that event should also be recorded. Audit evidence is not just about proving what was allowed. It is also about proving what was stopped. Without records of blocked actions, organizations cannot demonstrate that their governance controls are operating effectively.

What should an AI agent governance platform control?

These five controls establish the governance framework. The following controls define the decisions the platform can enforce and the evidence it records to demonstrate that those controls are working.

A use case: the budget rise that switched off two safety checks

For example, a finance department may set a monthly AI spending limit of $10,000, require customer data to remain within approved boundaries, and restrict access to payment systems. Every agent in the department inherits these controls automatically. If the agent limit is 10k$ and someone tries to change the limit for an agent, it goes for approval; nothing changes without an audit.

We learned this lesson the hard way. When we first implemented policy inheritance, a team-specific policy replaced the department policy entirely. The new policy introduced a budget limit, but it omitted the customer data and payment access controls already defined at the department level. As a result, those protections no longer applied to the agent.

The problem was not the budget rule itself. A routine policy change unintentionally removed existing safeguards.

That led us to a simple principle: policies can make controls more restrictive, but never less restrictive. A team can lower a spending limit set by the department, but it cannot raise it. It can add new restrictions, but it cannot override existing ones. Organizations already apply this principle in other areas of governance and delegation. We simply applied the same approach to AI agents.

All applicable policies are enforced together, and where multiple policies apply, the most restrictive rule takes precedence. For approvers, that simplifies the decision: a policy can add restrictions or tighten existing limits, but it cannot grant broader access or remove controls already in place.

This approach comes with a cost: legitimate exceptions require more effort. If a reconciliation bot genuinely needs broader access or higher limits, the change must be made to the governing policy and approved by the appropriate owner.

That additional effort is intentional. It ensures exceptions are explicitly reviewed and approved, rather than introduced inadvertently through a policy change.

What it is not

Not just an LLM gateway. While it can integrate with or include gateway capabilities, its primary role is centralized AI security, governance, policy enforcement, and runtime controls.

Not just content filtering. Content inspection is one control among many. The platform also governs agent identity, approvals, access, policies, and auditability.

Not an agent framework. Teams can continue building agents using their preferred tools and frameworks. The platform determines what those agents are allowed to do.

Not anomaly detection. The platform focuses on prevention, governance, and evidence. Detecting unusual agent behavior is a separate capability that complements these controls.

Where this stands today

This accelerator is designed as an implementable end-to-end architecture, with defined integration points for agent onboarding, identity, policy enforcement, AI security controls, model orchestration, tool governance, and auditability. 

You can register and govern your agents through centralized policies, while unauthorized access and policy violations can be denied, logged, and surfaced through the security and observability layers. The architecture supports automated validation and assertion-based testing to verify that security controls are consistently enforced across AI interactions.

The idea is not to introduce another standalone AI platform, but to provide a practical enterprise control model that can be implemented incrementally using existing security, cloud, AI gateway, governance, and observability investments. 

You can adopt the components that align with your current architecture and progressively strengthen AI governance as adoption evolves, from securing individual model interactions today to governing multi-model, agentic, and autonomous AI workloads tomorrow. 

If you are building agents inside your organization and want a route to scale up production that will survive security and FinOps review, let’s talk!