Why agents need an access control plane

Most teams adopt agents the same way: an engineer adds an MCP server to their editor, pastes an API key into a config file, and gets something useful done in an afternoon. Then a second engineer does the same with a different key. Six months later, nobody can answer a simple question from the security team: which agents can touch production data, and who gave them that access?

The sprawl problem

Each MCP server you configure on a laptop is a separate trust decision. It carries its own credentials, its own scope and its own logging, if it logs at all. Multiply that by every developer, every tool and every project, and you get:

• long-lived credentials scattered across machines,
• no single place to revoke access when someone leaves,
• no record of what an agent actually did.

One endpoint, many grants

A control plane flips the model. Agents connect to one MCP endpoint. Behind it, administrators register tools, MCP servers, skills, databases and APIs once, and grant them to roles, teams and projects. When a member's agent lists tools, it sees only what that member is allowed to use.

Secrets stay on the server. The agent asks to run query_orders; the gateway injects the database credential, runs the call and returns the result. The plaintext never reaches the model.

Guard rules and audit

Grants answer who can use what. Guard rules answer what should never happen, written in plain language and checked before every action. And because every call flows through one place, every call can be written to an append-only, hash-chained audit log that your auditors can trust.

That is the difference between agents as a side project and agents as part of your production estate.