Governance and security policies for enterprise AI agents

Reviewed against MCP 2026-07-28, A2A v1.0 and the OWASP Agentic Top 10 By Rameshkumar Varanganti · Enterprise Integration Lead & Architect · Updated 1 November 2026 · 12 min read

Enterprise agents should never receive unrestricted credentials or unconditional permission to perform business transactions. An agent chooses its next step at runtime and can be confused, wrong or manipulated by content it reads. Governance therefore cannot live in the agent's prompt. It has to be expressed as policy that the platform enforces regardless of what the agent decides.

The policy model: decide outside the agent

The well-established access-control model splits responsibility in two:

• A policy decision point (PDP) evaluates a request against policy and returns allow, deny or a condition such as "requires approval".
• A policy enforcement point (PEP) sits in the request path, asks the PDP, and blocks, allows or pauses the call.

For agents, every tool call and every delegation to another agent is a request. The input to the decision is richer than in classic API security: the user, the agent, the tool, the arguments, the data classification, the amount, the time, and the chain of agents that led here. Policy engines such as Open Policy Agent (Rego) or Cedar let you write these rules as code, version them, test them and review changes like any other code.

Where to enforce policy

Enforce at more than one layer, so a single misconfiguration does not expose everything.

The gateway is the most important new layer because it is the one place that sees agent identity, user identity and the tool together. It is not the only check: downstream APIs and systems must keep enforcing their own authorization.

Five kinds of agent policy

1. Access policies

Who may use what. An agent may only discover and call tools listed for its role, and only on behalf of users who could perform the action themselves. Discovery is filtered, so tools an agent may not use never appear in its tool list.

2. Action policies

Limits on what a permitted tool may do: amount thresholds, record counts, allowed status transitions, and which actions need human approval. Read and write operations are separate tools with separate rules.

3. Data policies

Which data an agent may see and where it may go: classification-based redaction of personal or confidential fields in tool results, data-residency rules for which model endpoints may receive which data, and retention limits for agent logs and memory.

4. Operational policies

Rate limits, per-case budgets for tool calls, tokens and time, delegation depth limits, allowed time windows for batch-like actions, and circuit breakers that stop an agent when error or denial rates spike.

5. Lifecycle policies

Rules about agents themselves: every agent must be registered with an owner and risk tier, pass testing before it reaches production, have changes to prompts, models or tools reviewed, and be retired when no longer needed.

Example policy set

An illustrative policy for an HR assistant agent and a finance agent, written as pseudo-YAML for readability. In a real engine these would be Rego, Cedar or your gateway's policy language.

# Illustrative only
policy: hr-assistant
applies_to: { agents: [hr-assistant] }
tools:
  allow: [get_my_leave_balance, get_org_chart, get_policy_document]
  deny:  ["*salary*", "*bank*", update_employee]
data:
  redact_fields: [national_id, home_address, date_of_birth]
  users_may_only_read: self_and_direct_reports
limits: { calls_per_minute: 30, max_delegation_depth: 1 }

policy: finance-payments
applies_to: { agents: [finance-agent], tools: [create_payment_request] }
rules:
  - deny:    user.role not in [ap_clerk, ap_manager]
  - deny:    supplier.status == "blocked"
  - deny:    bank_details_changed_within_days < 30
  - approve: amount > 10000
    approver: role == ap_manager and approver != requester
    timeout: 24h then escalate_to: finance_controller
  - allow:   amount <= 10000 and po_match == "three-way"
require: [idempotency_key, trace_id]
audit:   [user, agent, tool, decision, amount, approver, trace_id]

How the finance policy evaluates real requests:

Designing human approval

• Approve actions, not conversations. Require approval for specific high-impact tool calls: payments, master-data changes, employee record changes, deletions, anything sent outside the company.
• Separate duties. The approver must not be the requesting user, and an agent must never approve its own proposal.
• Show evidence. Present the exact action, arguments, source documents and trace, not only the agent's summary. Agents can produce fluent, confident explanations of wrong conclusions.
• Handle silence. Set timeouts and escalation paths so cases do not wait forever, and never default to "approve" on timeout.
• Avoid approval fatigue. If approvers see dozens of trivial requests a day, they stop reading. Tune thresholds so approvals stay rare and meaningful.
• Use protocol support. MCP's Multi Round-Trip Requests and A2A's input-required task state let an agent pause for a person as a separate, logged step.

Security controls the policies rely on

Policies are only as strong as the controls that enforce them. These map to the OWASP Top 10 for Agentic Applications:

Agent lifecycle governance

1. Register. Record the agent's purpose, business owner, technical owner, risk tier, tools, delegates and data it touches.
2. Assess. Higher risk tiers (agents that write to finance or HR systems, or act autonomously) need security review and stricter policies.
3. Test. Before production, test with adversarial content: injected instructions in documents and emails, spoofed partner replies, oversized inputs and loops.
4. Release under change control. Treat changes to models, prompts, tools and policies as releases, reviewed and versioned.
5. Monitor. Watch denial rates, approval rates, cost, latency and unusual tool sequences, with alerts routed to the owner.
6. Review and retire. Re-certify access periodically and decommission agents, credentials and tools that are no longer used.

Audit evidence

For every agent action, you should be able to answer: who asked, which agent acted, through which chain of agents, which tool with which arguments, what policy decided, who approved, and what changed in which system. Log metadata and summaries rather than full payloads, redact personal data, protect logs against tampering, and link everything with one trace ID. Regulations such as the EU AI Act include record-keeping and human-oversight requirements for some high-risk AI systems, so design these records in from the start.

Who owns what

Checklist

• Write agent policies as code, versioned and reviewed.
• Evaluate policy outside the agent and enforce it at the gateway and downstream.
• Filter tool discovery to permitted tools only.
• Cover access, action, data, operational and lifecycle policies.
• Require approval with separation of duties for high-impact actions.
• Carry user, agent and service identity on every call; exchange tokens per hop.
• Redact personal data and keep secrets out of prompts and memory.
• Register every agent with an owner and risk tier; test adversarially before go-live.
• Keep a kill switch per agent and per tool.
• Log tamper-evident audit records linked by trace ID.

FAQ

What is AI agent governance?

It is the set of policies, processes and controls that decide what AI agents may do in an organization, for whom, on which data and within which limits, and that keep a verifiable record of what they did.

Can't we just tell the agent the rules in its prompt?

Prompt instructions help the agent behave well, but they are not a control. An agent can misunderstand them or be manipulated by content it reads. Rules that matter must be enforced outside the agent by the gateway, APIs and systems of record.

Which actions should need human approval?

Actions that move money, change master data or employee records, delete data, or send information outside the company, plus anything above a risk threshold your process owner sets. Keep the list short enough that approvers still read each request.

What is the difference between agent governance and agent security?

Governance decides what agents should be allowed to do and who is accountable. Security makes those decisions enforceable and resistant to attack through identity, least privilege, validation, containment and audit. You need both.

Sources and further reading

• OWASP Top 10 for Agentic Applications 2026
• NIST AI Risk Management Framework
• RFC 8693: OAuth 2.0 Token Exchange
• Open Policy Agent documentation
• Cedar policy language
• Model Context Protocol: 2026-07-28 key changes

Related guides

• OWASP Agentic Top 10 mapped to integration controls
• Agent identity and authorization
• Multi-agent orchestration for enterprise integration
• MCP gateway architecture

← Back to knowledge library