--- title: "The MCP Broker" slug: "chapter-11-the-mcp-broker" kind: "chapter" order: 12 label: "Chapter 11" chapter: 11 part: "The Data Layer" partLabel: "Part III" partNumber: 3 epigraph: "Credentials reach tools through the broker, never through the agent. Everything else about governance follows from that sentence." summary: "Connectors give agents reach. The broker gives the institution control over that reach. It is the single component in a sovereign data layer that most AI products do not have, and its absence is wh…" words: 1136 topics: - "The piece most vendors skip" - "What the broker holds" - "Deny by default" - "Scoping every call to the person" - "The audit line" - "Why the broker belongs to the institution" --- Connectors give agents reach. The broker gives the institution control over that reach. It is the single component in a sovereign data layer that most AI products do not have, and its absence is why so many deployments either lock agents out of real data or let them see too much. This chapter is about what a broker is, what it holds, and why it must be the institution's. ## The piece most vendors skip In a typical agent product, the agent holds its own credentials. The connector to the CRM is configured with an API key; the key lives in the agent's environment; when the agent decides to call the CRM, it does so directly. This is simple, and it fails in every way that matters. The credential is wherever the agent runs, which may be a cloud service, a user's browser, or a desk-side machine, and it is as safe as that environment. The agent calls the system with the credential's full authority, not the user's. There is no central place to say "this agent may read but not write," or "this role may not call this tool at all." And the log of what was called, by whom, on whose behalf, is scattered across connectors or does not exist. A broker fixes all four problems by introducing one component between every agent and every tool. ## What the broker holds The broker is a service, inside the institution's perimeter, that every tool call passes through. It holds three things. **The credentials.** The API keys, service identities and OAuth grants that connectors need to reach systems of record live in the broker's secret store, not in any agent. An agent that wants to call a tool asks the broker; the broker, if the call is allowed, attaches the credential and forwards it. The agent never sees the key. A compromised agent, a leaked prompt, a stolen laptop running the browser extension: none of them yields a credential, because none of them ever held one. **The policy.** A table that says which roles may call which tools, with what scopes, on which agents. Read access to the student information system for advising roles. Write access to the ticketing system for support agents only. No access to the payroll connector for anyone except the HR agent, and then only to specific fields. The policy is data, editable by an administrator, versioned and auditable. **The audit log.** Every call: timestamp, agent, user, role, tool, parameters, result size, decision. Written to a store that the broker itself cannot alter after the fact. ## Deny by default The policy evaluation has one rule that every CIO should insist on: deny by default. A tool call that no policy explicitly allows is refused. The alternative, allow by default with exceptions, is how most integration platforms work, and it means that every new connector, every new agent and every new role starts with maximum access until someone remembers to restrict it. Deny by default inverts the burden. A new connector exposes nothing until an administrator grants a role access to specific tools. A new agent can call nothing until it is placed in the permission tree. The institution's exposure grows only by deliberate acts, each of which is logged. The practical cost is a little friction at setup, which the platform should make easy with templates. The practical benefit is that the answer to "what can this agent reach" is always "exactly what we said, and here is the table." ## Scoping every call to the person Chapter 10 argued that connectors should call systems as the asking person. The broker is where that happens. When a user asks an agent a question and the agent decides to call a tool, the request that reaches the broker carries the user's identity, verified through the identity layer from Part IV, and the agent's identity. The broker looks up the user's role, checks the policy for that role, agent and tool, and if the call is allowed, decides how to authenticate to the source system: as the user, by exchanging the user's token for one the source system accepts; or with a scoped service credential that the policy limits to what that role may see. Either way, the source system's own permission model applies, and the broker's policy applies on top. A student cannot see another student's record because the student information system will not return it under their identity, and because the advising agent's policy restricts the lookup tool to the caller's own ID. Two independent controls, neither of which depends on the model behaving. ## The audit line The audit log is the artefact that turns a sovereign deployment from a security posture into evidence. Because every tool call passes through the broker, the log is complete by construction. There is no path from an agent to a system of record that bypasses it. When a regulator, an auditor or a CISO asks what the AI has touched, the answer is a query over one table: which agents read patient records last month, under which users, how many calls, what was returned. When something goes wrong, the investigation starts with a filter, not with a search through connector logs that may or may not exist. The log also feeds operations. Spend by tool and by agent. Which connectors are busy and which are dead. Which roles are hitting the policy wall, suggesting a missing grant or a misuse attempt. A broker with a good log is the control room for the data layer. ## Why the broker belongs to the institution A vendor can run a broker in its own cloud, and some do. That recreates the problem the broker solved. The credentials to every institutional system would live in the vendor's secret store; the policy would be enforced on infrastructure the institution does not control; the audit log would be the vendor's to retain or lose. The sovereign requirement is that the broker runs inside the institution's perimeter, on the same tier as everything else from Chapter 3: the institution's cloud account, its servers, or behind its air gap. The credentials never leave. The policy is the institution's. The log is the institution's. And when the vendor relationship ends, the broker, the connectors and the policy table keep running, because they were never the vendor's to take. A CIO evaluating a platform can test this in one question: where is the secret store that holds the credentials your connectors use to reach my systems? If the answer is anywhere other than infrastructure the institution controls, the data layer is not sovereign, whatever the connectors can do. The next chapter adds the last piece of the layer, the ontology that gives agents a shared vocabulary for the institution without copying it.