AI Governance Best Practices for Agentic Tool Access

When an AI model generates content, it produces an output, and a human decides what happens next. An AI agent skips that step. It invokes tools, calls APIs, writes to systems, and chains decisions on its own, so a governance failure stops being a bad paragraph someone has to edit. It becomes an unauthorized action with real-world effects: a payment sent, a file deleted, a record changed in a production database. A single agent can run dozens of tool calls to finish one task, spawn sub-agents that inherit their own tool access, and reach into CRMs, code repositories, cloud infrastructure, and financial systems, all faster than any human reviewer could track in real time. The Cloud Security Alliance's Agentic AI Governance paper states the mismatch directly: the NIST AI RMF's four-function structure of Govern, Map, Measure, and Manage is a well-established governance architecture, but it "was not designed to address the distinctive hazards that arise when AI systems can autonomously chain decisions, escalate privileges, interact with external services, and produce real-world effects at machine speed." The mechanism behind most of these failures is an old one with a new engine: the "confused deputy" problem, where an agent is granted broad permissions so it can function, and an adversary crafts an input that tricks the agent into using those permissions somewhere it shouldn't. The systems themselves were built around a loop that no longer describes how agents operate.

Deployment speed outrunning organizational controls

Agent deployment has grown so fast that most organizations now govern systems they cannot fully see, with controls that stop at the edge of where agents actually operate. The Island AI Agent Governance analysis names the core mismatch directly: platform-layer controls can confirm what an agent was configured to do, but they cannot see what it actually did inside a user's browser tab, terminal, or desktop app. A large share of deployed agents run with no security oversight or logging attached to them, and only 21% of executives say they have complete visibility into agent permissions, tool usage, or data access patterns. But most of those same executives still say they're confident their existing policies protect against unauthorized agent actions, and if you're responsible for either, that gap between confidence and visibility should worry you. Early security assessments of public MCP servers found widespread command injection flaws, unrestricted URL fetches, file path traversal vulnerabilities, and a majority lacking authentication. These are not hypothetical risks sitting in a threat model somewhere. They describe the current baseline of ungoverned deployment, running right now, in production, across organizations that believe their policies already cover it. None of this can be fixed by writing a better policy document, because a policy cannot protect what it cannot locate: controls only work on systems an organization knows exist, and that starting point, an inventory of what's actually running, is where governance has to begin.

What regulators and standards bodies are now requiring

Regulatory pressure on agentic AI is no longer abstract, and the guidance arriving now is specific about what organizations must achieve, even where it says little about how to build it. On May 1, 2026, six national cybersecurity agencies, CISA, the NSA, Australia's ASD ACSC, the Canadian Centre for Cyber Security, New Zealand's NCSC, and the UK's NCSC, jointly published "Careful Adoption of Agentic AI Services," which groups agentic risks into five categories: privilege, design and configuration, behavioral, structural, and accountability. The guidance calls for continuous runtime authentication, with centralized policy decision points evaluating each action an agent takes throughout its connection to a system. NIST's Center for AI Standards and Innovation launched its AI Agent Standards Initiative in February 2026, and that same month the NCCoE published a concept paper on applying identity standards to software agents; it's an early-stage proposal, but one that signals where federal expectations are headed. The 2026 Singapore Consensus goes further, synthesizing international research priorities into ten agentic risk management principles spanning design and development, testing and deployment, and operation and monitoring: least privilege, traceable identity, auditability, validated deployment, adversarial resilience, multi-agent stability, runtime assurance, interruptibility, legibility, and human oversight.

None of this guidance can close the gap between requirement and enforcement on its own. The clearest illustration sits inside the Model Context Protocol itself. Its Enterprise-Managed Authorization extension, promoted to stable status on June 18, 2026, controls whether a user is allowed to connect a client to a server. It does not inspect MCP traffic after that connection token has been issued. An organization can satisfy EMA's requirement completely and still have no idea what an agent does once it's inside a system. A fair question follows: if the Five Eyes guidance and the EU AI Act already set the requirements, why isn't compliance with them enough? Because that guidance specifies outcomes, least privilege, audit trails, human approval gates, without specifying the enforcement architecture that produces them. If a policy says an agent should only use billing tools, that does nothing to stop the agent from calling a payment tool, if that tool is sitting in its available tool list. Regulators are telling organizations what good governance looks like. Building the thing that enforces it is still the organization's job.

Agent inventory as the prerequisite for every other control

Access controls, audit trails, and incident response plans all depend on knowing an agent exists in the first place, which makes inventory the condition that makes every other control possible, not simply the first item on a checklist. The Five Eyes guidance, the Maxim AI governance best practices, and the Singapore Consensus open their respective control sets with the identical requirement: catalogue every deployed and planned agentic AI system, along with its tool access, data access, authorization patterns, and interactions with external services. A complete inventory has to reach past centrally deployed servers and into what's running on individual endpoints, the MCP servers, skills, and AI extensions installed on developer laptops and inside browser sessions, because that's where most ungoverned deployment actually happens. Every production MCP server needs an owner, a stated purpose, and a defined lifecycle. An agent without those three things has no accountability chain attached to it and no trigger that tells anyone when it should be decommissioned.

Pinterest's implementation, rolled out in March 2026, shows what this looks like when it's done well. Every production MCP server at the company must be owned by a specific team, listed in an internal registry, and pushed through a review that generates Security, Legal/Privacy, and GenAI review tickets where applicable, all of which have to be approved before the server goes live. That governed structure produced 66,000 monthly invocations across 844 active users, a scale of adoption that came from a deliberate review process. The objection to registry-centric governance is a fair one: formal review processes slow teams down, and developers lose the ability to spin up an experimental server on a whim. Review should be sized to the risk, not skipped. If a registry is easy to add to, it costs far less time than the incident investigation that follows an agent nobody knew existed. Shadow AI is what happens when teams have no governed path to the tools they want, so they build an ungoverned one instead. A working registry is what removes the reason to do that.

Agent identity and least-privilege access in practice

Knowing what agents exist only answers half the question. What each one can reach matters just as much, so the control treats every agent as its own non-human identity, with credentials that are scoped and time-limited rather than borrowed from somewhere else. Most existing identity and access management platforms weren't built with agent-class principals in mind, so they need real augmentation to handle this correctly. When an agent borrows a user's logged-in session or runs under a shared service account, it inherits everything that account can reach. Accountability disappears at that moment, and least privilege is gone the instant the agent starts working under someone else's identity. The Island analysis names this exact moment as where even well-run identity programs get caught off guard: the agent isn't a new user that needs a new account; it's an entirely new category of actor that existing provisioning processes never anticipated.

The stronger model gives every production agent its own identity: an owner, a stated purpose, a defined lifecycle, and credentials that are issued just-in-time, scoped to a single task, and set to expire the moment that task ends. The Five Eyes guidance is explicit about this: agent identities should be cryptographically anchored, credentials should be short-lived, and any agent that needs privileged access should get it through just-in-time provisioning, with that access automatically revoked once the task completes. Pinterest's enforcement pattern shows what this looks like at the tool level. Inside its servers, individual tools carry lightweight decorators, such as @authorize_tool(policy='...'), that restrict access directly. A revenue metrics tool, for instance, can be locked to a single finance team and nobody outside it. That restriction lives in the tool definition itself.

That distinction is the sharpest point in agent security right now. Telling an agent, in its instructions, to "only use billing tools" does not stop it from calling a payment tool, if that payment tool is sitting in its available tool list. An agent follows the tools it's handed, and language in a prompt is a suggestion, not a boundary. The only enforcement that holds is removing the tool from the agent's reach entirely, at the point where tools are defined and granted. Policy that lives only in a prompt provides the appearance of governance without the substance of it. Least privilege has to extend to the supply chain behind these tools too: cryptographic signatures and software bills of materials for all server code, mandatory code-signing verification before anything gets installed, private package repositories with active security scanning, and allow-lists of approved MCP servers that have been through a documented security review.

Proportional autonomy tiers as a practical alternative to "lockdown or trust"

A Gartner analysis, cited by Island, found that most enterprises treat agent governance as a binary choice, "either locked down or fully trusted, and that is the root cause of failure." The same analysis predicts that a significant share of enterprises will demote or decommission their autonomous AI agents by 2027, after governance gaps appear as production incidents rather than planning reviews. Treating every agent the same way, regardless of what it's actually capable of changing, pushes teams toward the exact shadow AI that governance is meant to prevent: when the only options are full lockdown or full trust, teams denied access build their own unsanctioned path around the restriction.

A four-tier model, drawn from the Island analysis, the Singapore Consensus, and the Five Eyes guidance, replaces that binary with controls that scale to what an agent can actually do. At the first tier, an agent reads and logs information without changing any system state, and it needs only minimal controls around it. At the next tier, an agent drafts recommendations or content, but a human reviews the output before anything moves forward. At the Act with Approval tier, the agent can execute actions directly, but a human has to approve each step that changes system state. At the Act Autonomously tier, the agent operates within a narrow, well-understood scope, under rate limits and with a kill switch available, reserved for tasks where the blast radius of a mistake is small and well understood.

This structure changes the question an organization has to answer. Instead of asking whether an agent can be trusted, which has no stable answer and tends to default to no, the tier model asks how much that agent can change, a question with a factual answer that can be reassessed as the agent's scope grows or shrinks. When teams get a governed path to the tools they actually want, they cut down on shadow AI far more than teams that simply block access and hope the demand goes away. The tier structure is what makes that governed path credible, because it doesn't force every use case through the same lockdown regardless of risk. Pinterest's registry approach is the proof this works at scale: formal review for every server, applied consistently, produced a system handling tens of thousands of monthly invocations and thousands of hours of documented time savings. Governance, built this way, is what let that system scale.