Bain Says Every Agentic Platform Needs a Policy Layer. We Built One.

Bain & Company published a framework for agentic AI architecture this month. The core argument: enterprise platforms need three layers — orchestration, observability, and governed data access. Bolted-on governance doesn’t work. Security has to be structural.

The part that caught our attention was this: they call for a “centralised registry and policy layer to govern agent access” with “runtime guardrails” and “tool entitlements” enforced at the platform level. They name MCP explicitly as the protocol agents use to discover and invoke tools.

They’re describing the architecture. We built the enforcement layer.

The structural gap Bain identifies

The Bain paper, authored by Eric Sheng, Roger Zhu, Brendan O’Rourke, Dale Pedzinski, and Kevin Zhang, makes a specific diagnosis: legacy enterprise AI platforms were built for single models behind static API endpoints. Identity and access controls assume human users in role-based sessions — not autonomous agents that need contextual, least-privilege permissions for every tool call.

That mismatch is already causing damage. Agents discover tools dynamically via MCP servers. They share session state and persistent memory. They invoke other agents. The result: autonomous systems operating with human-shaped access controls that don’t fit.

Bain’s framework puts policy enforcement inside the orchestration layer — not as an afterthought, not as a monitoring dashboard, but as a runtime enforcement point that evaluates every tool call before it executes.

What their framework prescribes

The three-layer architecture breaks down as follows:

Application and orchestration layer — the command centre. Manages multi-step workflows, tool routing, and agent coordination. This is where Bain places the policy layer: an agent registry with defined capabilities, tool entitlements, and policy constraints. Every tool call is evaluated against policy before reaching upstream.

Analytics and insight layer — real-time visibility into agent execution. Full reasoning-path traceability from prompt to tool invocation to output. Alignment monitoring for behavioural drift.

Data and knowledge layer — governed data access across structured and unstructured stores. Schema contracts, federated catalogues, real-time streaming.

The critical point: these aren’t optional add-ons. Bain argues that security and governance must be embedded across layers from day one. Organisations that bolt governance on after deployment are structurally exposed.

Where Intercept fits

Intercept is an open-source proxy that sits between AI agents and MCP servers. It enforces YAML-defined policies on every tool call: rate limits, spend caps, argument validation, access controls, human-in-the-loop approval. The call passes, gets held for approval, or gets blocked.

That maps directly to what Bain describes:

Bain’s requirement	Intercept implementation
Centralised policy layer	Single proxy, one YAML file per server
Tool entitlements	Default-deny mode — agents only access listed tools
Runtime guardrails	Sub-millisecond policy evaluation on every call
Agent access governance	Rate limits, spend caps, argument validation per tool
Audit tooling	Every decision logged with rule, action, and reason
Non-human identity controls	Per-agent, per-tool policy enforcement

The architecture Bain prescribes at the theoretical level — Intercept implements at the transport layer.

# Bain's "tool entitlements" in practice
version: "1"
default: deny

tools:
  list_customers:
    rules: []

  create_charge:
    rules:
      - name: "spend-cap"
        spend:
          per_call: 500.00
          daily: 5000.00

  delete_customer:
    rules:
      - name: "require-human"
        action: require_approval
        approval_timeout: "30m"

Default deny. Explicit tool entitlements. Spend enforcement. Human-in-the-loop for destructive operations. This is what “governed agent access” looks like in a config file.

Why this matters for enterprise teams

If you’re building an agentic platform and your architecture doesn’t include a policy enforcement layer, Bain is telling you it should.

The question isn’t whether you need one. It’s whether you build it yourself or use something that already exists.

Building in-house means implementing: policy evaluation engines, stateful rate limiting, spend tracking with rollback, approval workflows with fingerprinting, multi-transport support (stdio, HTTP, SSE), persistent state across restarts, hot-reload without downtime, and audit logging across every decision.

Intercept ships all of this as a single binary. One command to set up:

npx -y @policylayer/intercept init

It scans your MCP config, discovers every tool across every server, and opens a web UI where you assign policies. Protected tool calls in 30 seconds.

The convergence

Bain isn’t the only one reaching this conclusion. The pattern is converging across the industry: agents need deterministic controls at the tool-call level, not probabilistic guardrails at the prompt level.

Prompts tell the agent what it should do. Policy layers define what it is allowed to do. The difference is enforcement — and enforcement is what Bain is calling for.

The three-layer architecture they describe is the right frame. The policy layer they prescribe is the piece most teams are still missing. Intercept exists to fill that gap.

---

Ready to add the policy layer Bain describes?

• Get started — open source, Apache 2.0
• Policy templates — ready-made policies for Stripe, GitHub, AWS, and more
• Read the Bain paper — the full framework