In The Five Pillars of AI Agent Accountability: A Diagnostic Framework for Engineering Leaders, we walked through each pillar of AI agent accountability (traceability, authorization provenance, identity and ownership, policy at scale, and human oversight) and argued that most enterprises today sit at Level 0 or Level 1 of the Accountability Maturity Model.
The most common reaction we get when we share that framework is some version of: “We’re already covered. We have network policies. We have an API gateway. We have RBAC.”
This article is for that reaction.
Enterprises aren’t starting from zero. Most have invested in security, networking, and identity infrastructure that works well for traditional workloads. The problem isn’t a lack of tools. It’s that existing tools were designed for model outputs, not autonomous actions; a world where services are deterministic, communication patterns are predictable, and humans make all the decisions.
Agentic AI breaks every one of those assumptions. Here’s where the most common approaches each leave a critical accountability gap.
Network policies: the wrong abstraction level
Kubernetes Network Policies are essential for securing any cluster. They restrict which pods can communicate with which other pods at the network level, and they should absolutely be part of your security posture.
But network policies operate at the wrong abstraction level for agent accountability. They can say “pods in namespace A can reach pods in namespace B.” They cannot say “Agent A with risk-level=low can only call agents with risk-level=low.” They have no concept of agent identity, capabilities, or policy attributes.
More critically, network policies produce no audit trail. When a connection is allowed, there’s no record of why it was allowed; no policy name, no attribute match, no traceable decision. When your compliance team asks “was this interaction authorized by policy?” a network policy gives you nothing to show them.
Accountability gap: No agent-level authorization, no audit trail, no provenance.
API gateways: built for north-south, not agent-to-agent
API gateways (e.g. NGINX, Kong, Envoy, cloud-native gateways) are designed for request routing, rate limiting, and basic authentication. They work well for north-south traffic: external clients accessing internal services.
But agent-to-agent communication is east-west traffic between internal services, often with complex multi-hop chains. API gateways don’t understand agent identities, don’t evaluate agent-specific policies, and don’t produce agent-aware audit trails that correlate across multiple hops.
An API gateway can tell you “a request came from IP 10.0.3.47 and was routed to service X.” It can’t tell you “Agent A (owned by the finance team, risk-level=medium) called Agent B (owned by the compliance team, capability=audit-query) and this was permitted by policy P-2847.”
That’s the level of detail your compliance team needs. An API gateway will never give it to them.
Accountability gap: No agent identity awareness, no policy evaluation, no multi-hop trace correlation.
MCP and A2A protocols: communication without governance
The Model Context Protocol (MCP) and Agent-to-Agent (A2A) protocol represent major progress in standardizing agent communication. MCP standardizes how agents connect to tools. A2A standardizes how agents coordinate with each other.
Both are important infrastructure. And both explicitly assume that someone else handles governance.
- MCP solves the how of tool access: A consistent protocol for discovering and calling tools. It does not solve the who: which agents are allowed to access which tools, under what conditions, and with what audit trail.
- A2A solves the how of agent coordination: Capability discovery, task delegation, lifecycle tracking. It does not solve the who: which agents are allowed to delegate to which other agents, or who is accountable when a delegated task goes wrong.
These protocols are necessary but not sufficient. They are the plumbing, not the governance. Using MCP without agent governance is like having HTTP without authentication; the communication works, but anyone can call anything.
Accountability gap: Protocols handle communication mechanics, not authorization, policy enforcement, or audit.
DIY security patterns: four tools, no unified policy layer
The O’Reilly book, Generative AI on Kubernetes (2026), documents four security patterns for securing MCP communication: token passthrough, service account delegation, OAuth2 token exchange, and mTLS with SPIFFE/SPIRE. Each pattern is sound on its own.
The problem is that implementing all four creates four disconnected systems with no unified policy layer:
| Pattern | What it does | What it misses |
| Token passthrough | Propagates user identity through hops | No agent-level policy evaluation |
| Service accounts | Authenticates workloads | Loses user attribution |
| OAuth2 token exchange | Preserves both identities | Requires a separate token- exchange service to operate |
| SPIFFE/SPIRE mTLS | Cryptographic workload identity | No knowledge of agent capabilities or team ownership |
None of these patterns produce a correlated audit trail that spans the full agent interaction chain. None evaluate declarative policies based on agent attributes. None provide a dashboard for human oversight of agent communication patterns.
Building accountability from these primitives is like building a car from raw steel, technically possible, but nobody should have to do it from scratch. We’ve seen platform teams sink six to twelve months of engineering into stitching this together, only to discover they still can’t answer the auditor’s question.
Accountability gap: Fragmented security, no unified policy layer, no correlated audit, significant engineering investment required.
RBAC alone: doesn’t survive agent #101
Role-Based Access Control is the default model for most authorization systems. Assign agents to roles, grant roles permissions, done.
RBAC works at a small scale. With 10 agents and 3 roles, the matrix is manageable. But RBAC requires explicit enumeration, where every agent must be assigned to a role, and every permission must be granted to a role. When you add agent #101, someone must decide which role it belongs to and update the bindings.
More fundamentally, RBAC cannot express the nuanced policies that agent governance requires:
- “Agents with overlapping capabilities can communicate with each other.”
- “Low-risk agents can call low-risk agents, but medium-risk agents can call both low and medium.”
- “Agents on the same team can access that team’s MCP servers.”
These attribute-based policies are natural to express in English but impossible to model cleanly in RBAC without an explosion of roles. By agent #200, the role matrix is unmaintainable and new agents start getting deployed without governance, exactly the shadow agent problem we covered in our previous blog post, The AI Agent Accountability Crisis: Why Governance Isn’t Keeping Up With Deployment.
Accountability gap: Doesn’t scale, can’t express attribute-based policies, requires manual updates for every new agent.
| Approach | What it does well | Accountability gap |
| Kubernetes Network Policies | Pod-to-pod isolation | No agent identity, no audit trail |
| API gateways | North-south request routing | No east-west, no policy correlation |
| MCP / A2A protocols | Standardize agent communication | Communication, not governance |
| DIY security patterns | Per-pattern soundness | Four disconnected systems, no unified policy |
| RBAC | Simple at small scale | Doesn’t scale well with large amount of agents, no attribute policies |
The AI agent accountability layer is the missing piece
Every existing approach covers part of the problem. None of them, alone or stacked together, deliver AI agent accountability. The missing piece is the unified layer above them.
The industry has solved agent communication (MCP, A2A) and agent infrastructure (Kubernetes, GPUs, model serving). What’s missing is the accountability layer, the control plane that answers three questions for every agent interaction:
Effective human oversight means:
- Who authorized this? Traceable to a specific, auditable policy.
- What policy permitted it? With attribute-based evaluation, not hardcoded names.
- What’s the full record? End-to-end distributed trace with every hop, decision, and outcome.
The immaturity of the space is striking. A recent review of 43 AI risk frameworks found that only two even addressed agent-specific risks. This is the gap that will determine which enterprises can scale agentic AI responsibly, and which will be forced to cancel projects, face compliance failures, or deal with incidents they can’t investigate.
Common questions about AI agent accountability
Aren’t network policies enough if I’m using a service mesh?
No. A service mesh adds mTLS and routing, but its policy layer still operates on workload identities and namespaces, not agent capabilities, owners, or risk levels. You still can’t produce an audit trail that names which policy permitted a specific agent-to-agent call, or scale that policy without manual updates.
Can I add an authorization layer on top of MCP myself?
You can, and many teams are trying. The hard part isn’t the policy engine; it’s the audit correlation across multi-hop chains, the dual identity verification (workload + user), the visual oversight surface, and the attribute-based policy model that scales. Stitching those together is a 6–12 month engineering investment that delivers a worse outcome than purpose-built tooling.
What about ABAC instead of RBAC?
Attribute-Based Access Control (ABAC) is on the right track, it’s exactly the model AI agent governance needs. But ABAC by itself is a policy language, not a complete platform. You still need agent identity, agent registration, attribute population, audit correlation, and a human oversight surface around it. ABAC is a piece of the answer, not the whole answer.
Does Tigera’s solution replace these tools?
Tigera’s solution complements them. Network policies still secure your cluster. Service meshes still handle mTLS. MCP and A2A still standardize agent communication. Our platform adds the accountability layer above them, the layer that answers who, what, and why for every agent interaction.
Key takeaways
- Network policies, API gateways, MCP/A2A protocols, DIY security patterns, and RBAC each solve a different problem; none of them solves AI agent accountability.
- The missing layer is the accountability layer: the one that ties identity, policy, and audit together across every agent interaction.
- Without that layer, your compliance team has no answer to “which policy permitted this?”
- Building it from primitives is technically possible, but it’s a 6–12 month investment that still leaves gaps.
Get the strategic guide for accountable AI agents
If your team is currently trying to assemble accountability from network policies, OAuth2 exchange, SPIFFE, and a homegrown policy engine, then read our guide first.
Accountable AI Agents: A Strategic Guide for AI & Security Leaders Governing Autonomous AI at Scale covers the full framework: the five pillars, the maturity model, the principles, and the three-step roadmap. No code, no product demos. Just what your leadership team needs to make the build-vs-buy call.
Get the strategic guide for accountable AI agents →
The post The AI Agent Accountability Gap: Why Network Policies, API Gateways, And RBAC Are Not Enough appeared first on Tigera – Creator of Calico.
