For two years the enterprise AI governance conversation was about output: what the model says, whether it invents a fact, who signs off before it reaches a customer. That question has quietly been replaced. At Black Hat 2026 in late July, Snowflake launched Cortex AI Gateway, a centralized Model Context Protocol gateway enforcing identity, policy, and audit at the tool-call level across more than 100 MCP servers. On July 22, OpenAI shipped Presence, whose control set includes permission limits on which data and systems an agent may touch. On July 7, Codenotary shipped AgentMon 3, which learns baselines from observed agent activity and adapts runtime policy against them. Three companies attacking the problem from data, model, and runtime security landed on the same control point in the same month. The risk in an agent deployment is no longer the sentence it produces. It is the tool call it makes, the credential it borrows, and the data that leaves the building.
The tool-access layer is the connective tissue between a model and the systems it acts on: the servers, connectors, and protocol endpoints that turn generated intent into a database query, a ticket update, a file read, or an outbound API call. MCP has become the common way enterprises expose those tools, which is exactly why it is worth governing. A protocol that standardizes how agents reach systems also standardizes where you can stand to inspect them. Protocol-level authorization is necessary but not sufficient: it can decide whether a given server should honor a given call, and it still leaves you without a cross-server inventory, egress inspection, or a unified audit trail. That gap is the case for a chokepoint.
Output governance and access governance answer different questions with different tools. Output governance asks whether the answer was accurate and on-policy, evaluated with reviews, evals, and red teams. Access governance asks what the agent could reach, under whose authority, and what crossed the boundary, evaluated with identity systems, authorization policy, egress inspection, and logs. Doing the first well tells you nothing about the second.
An IT director should be able to answer three questions without opening a laptop. What systems can this agent reach right now, and who approved that list? Whose identity does it present, and can a given tool call be attributed to a specific agent? What data can leave through a tool response, and what stops a legitimate call from returning ten thousand records instead of ten? If any answer is a person's name rather than a control, you have a convention.
Tool-layer control became a product category rather than an application concern. Three markers from July 2026, from Snowflake, OpenAI, and Codenotary.
You cannot govern an agent by governing its prompt. Governance has to sit where the agent touches your systems: a chokepoint that knows which agent is calling, what it may call, and what data the response carries back out. If you cannot name that chokepoint today, you have an access-control gap no amount of model evaluation will close.
Ungoverned agent tool access rarely looks like a breach. It looks like a productive department that stood up its own agents, wired them to systems with credentials already lying around, and told nobody. Five patterns recur, and each is an access problem rather than a model problem.
Identity: shared service accounts and human tokens.
Authorization: whatever the connector was granted at setup, permanently.
Egress: unbounded. Volume and destination unmeasured.
Inventory: unknown server count, no recertification.
Audit: conversation transcripts. Tool calls invisible.
Failure mode: a quiet data event you learn about from someone else.
Identity: a distinct machine identity per agent, with a lifecycle and an owner.
Authorization: per-tool allowlist, scoped sessions, approval on high blast radius calls.
Egress: responses inspected against classification, with volume and destination limits.
Inventory: a registry with owner, purpose, and a recertification date.
Audit: every call logged with identity, decision, parameters, and data returned.
Failure mode: a blocked call and an alert, a tuning problem you can see.
MCP governance is the practice of putting four control families at the tool-call level rather than the application level, in this order, because each makes the next enforceable: identity, authorization, egress, and audit. A gateway product can deliver all four, and so can a well-configured API gateway plus your existing identity provider, if the discipline is real.
Issue every agent a distinct machine identity with an owner of record, a defined lifetime, and automated rotation. Ban agents authenticating as humans. Require that identity in every tool call so attribution is a property of the system rather than an investigation. This is the ground we covered in agent identity and access management, and it is the prerequisite for everything below: you cannot scope, inspect, or audit a principal you cannot name.
Move from "the agent has access to the CRM" to an explicit allowlist of the tools it may invoke and the operations within them. Scope sessions so a long-running agent cannot accumulate reach. Then split actions by blast radius: reads inside a classification boundary run freely, writes and configuration changes take a policy check, and deletes, payments, external sends, and bulk exports need approval from a named human. Most agent value sits in the first tier and most agent risk in the last.
The realistic data-loss scenario is not a stolen token. It is a legitimate tool call returning material that should never have left its system of record, then carried into a transcript, a downstream tool, or a third-party model. Inspect responses against data classification, cap result volume, restrict destinations, and treat any external model endpoint as an egress boundary with its own policy. The exposure is concrete at the executive level: a permitted call that returns regulated data into a transcript or a third-party system is a disclosure your counsel may have to assess against breach-notification duties and customer contract terms, and the tool-call record is the evidence a SOC 2 auditor will want when testing logical access controls. This is where the execution layer stops being an abstraction.
Log every tool call with the agent identity, the authorization decision and the policy behind it, the tool invoked, the parameters, and a classified summary of what came back. Store it where the agent cannot alter it. Then run the test: pick a call from last week and reconstruct it end to end in under an hour. If you cannot, your logging is conversational rather than forensic. Pair this with the detection discipline in the agent monitoring gap.
Six metrics turn a policy document into an operating program. Report them monthly, to the audience that already sees patch compliance.
The first 90 days should run inventory, then identity and the chokepoint, then egress and audit, because sequence matters more than tooling. Buying a gateway before you know what it should front produces an expensive proxy over a partial inventory.
Most of this is architecture and operations rather than data science. Teams already running custom AI agents in production usually need the chokepoint named and identity cleaned up more than they need new tooling. Teams still in pilot have the advantage: build the access model and the agent together, inside your AI security and governance program from day one, and bring in an AI consulting partner if the identity team and the agent builders are not in the same conversation. We do this from our Dallas–Fort Worth home base and remotely across the country.
The governance question moved, and the tooling moved with it in a single month. What the model says is the easy half. What the agent reaches is the half with consequences: a borrowed identity, an inherited entitlement, an unlogged call, a permitted query that returned too much. Inventory what your agents connect to. Give each its own identity. Scope permissions to what is exercised, not what is convenient. Inspect what leaves. Log every call where the agent cannot edit it. Do that and agent expansion becomes a capacity decision instead of a risk you are quietly absorbing.
Infonaligy designs and operates governed AI agent estates from our Dallas–Fort Worth home base, and delivers them to teams across the country, remotely nationwide.
Book an assessment and we will inventory your MCP servers and connectors, map agent identities and standing permissions, and hand you a prioritized plan for the chokepoint, egress control, and tool-call audit trail.
Infonaligy