Policy-Driven Authorization for AI Agents with Kyverno and AWS AgentCore

Enforcing real-time, payload-aware governance for the agentic era

Introduction: From Generation to Action

AI agents are no longer just generating responses, they’re taking actions.

From invoking APIs to modifying infrastructure, agentic systems now operate directly on production environments.

This raises a critical question:

How do we control what an AI agent is allowed to do at runtime?

Standard IAM roles are excellent for identity and access management, but they are often too coarse-grained to understand:

• The context of a natural language prompt
• The intent behind an action
• The specific parameters of a tool call

What’s missing is a runtime authorization layer, one that evaluates every agent action dynamically before execution.

The Need for Runtime Authorization

AI agents operate in highly dynamic environments:

• A single prompt can trigger multiple tool calls
• Decisions are influenced by natural language input
• Actions may involve sensitive or destructive operations

Without proper authorization controls, this can lead to:

• Unauthorized system access
• Destructive operations in production
• Data leakage
• Prompt injection–driven misuse

Traditional IAM-based approaches are:

• Static
• Coarse-grained
• Not aware of request payloads

What we need is policy-driven authorization (AuthZ), evaluated in real time, based on context.

Architecture: MCP Governance Gateway

This solution introduces a runtime authorization layer directly into the agent execution path using a reusable architecture pattern.

At its core is the MCP Governance Gateway, which inserts a “security interceptor” between the agent and the tool it wants to execute.

Request Flow

1. Agent initiates a tool call
   An MCP client or agent runtime using Amazon Bedrock AgentCore Gateway decides it needs to invoke a tool (for example, delete-pod).
2. Gateway interception
   The AgentCore Gateway receives the request and routes it through an interceptor
3. Interceptor extracts context
   The Lambda interceptor captures:
   • User identity
   • Role
   • Tool name
   • Request parameters
4. Kyverno policy evaluation
   The request is sent to Kyverno (running in HTTP/AuthZ mode)
5. Policy decision
   • Kyverno evaluates the request against policies
   • Returns an authorization decision
6. Enforcement
   • ✅ ALLOW → Gateway invokes the tool
   • ❌ DENY → Gateway blocks execution and returns a 403
7. Audit logging
   • Decisions are recorded for observability and compliance

Authorization is enforced before execution not after.

Key Engineering Learnings

Building this architecture uncovered several important real-world constraints.

1. The “No VPC” Constraint

A key limitation:

The AgentCore Gateway cannot invoke Lambda functions deployed inside a VPC.

If your interceptor or tool Lambda is deployed inside a VPC, the Gateway will fail with an InterceptorException.

Solution:

• Deploy Lambdas without VPC configuration
• Expose Kyverno externally via:
  • Network Load Balancer (NLB), or
  • API Gateway

2. Interceptor Response Format is Strict

The Gateway expects a very specific JSON response format.

• For ALLOW → return transformedGatewayRequest
• For DENY → return only transformedGatewayResponse

Important:

Including both in a DENY response may cause the Gateway to ignore the denial and execute the request anyway.

Correct separation is critical for enforcement.

3. Policy-as-Code with Kyverno (HTTP Mode)

Kyverno evaluates authorization decisions using HTTP mode, where the interceptor forwards structured request attributes (such as headers and contextual fields) to the policy engine.

Instead of inspecting raw MCP protocol data, policies operate on normalized request attributes, including:

• Tool name
• Operation type
• Environment
• Query context

This approach keeps policies:

• Simple
• Deterministic
• Decoupled from protocol complexity 

Example: Blocking Destructive Operations in Production

A representative policy from this implementation prevents delete operations in production environments:

How This Works

1. The interceptor Lambda extracts request attributes and forwards them as headers
2. Kyverno maps those headers into variables (operation, environment)
3. The policy evaluates:
   1. Whether the operation is destructive (delete*)
   2. Whether the request targets a production environment
4. If both conditions are met → request is DENIED
5. Otherwise → request is ALLOWED

Getting Started

The full implementation  including:

• CloudFormation templates
• Interceptor Lambda
• Kyverno configuration

is available here:

https://github.com/nirmata/kyverno-bedrock-agentcore

Conclusion

As AI agents become more autonomous, authorization becomes a first-class concern.

Static permissions are no longer sufficient. Every action must be evaluated in context.

By introducing a policy-driven authorization layer with Kyverno, we move from reactive security to: Proactive control of agent behavior