Principle 11: Tool and Service Governance

This is the eleventh in a series exploring the 12 non-negotiable principles from our Agent Runtime Governance whitepaper. The whitepaper is based on experience building enterprise grade agentic infrastructures for clients. Each post dives into a single principle -- why it matters, what can go wrong, and what good looks like.

---

The first ten principles built a governance architecture that covers identity, execution, and operational resilience. Agents are identified, purpose-declared, authority-scoped, control-plane-enforced, lifecycle-tracked, human-overseen, policy-governed, memory-classified, observable, and failure-safe.

All of that governs the agent itself. Its identity. Its authority. Its lifecycle. Its memory. Its failure modes. But agents do not exist in isolation. They act on the world through tools and services. Every meaningful thing an agent does, querying a database, calling an API, sending an email, modifying a record, happens through a tool invocation. Tools are how agents translate reasoning into action.

And here is the problem: a perfectly governed agent that connects to an ungoverned tool is still an ungoverned system. The governance boundary ends where the tool call begins. If you control everything about the agent but nothing about what it connects to, you have built a locked door with an open window.

Principle 11 addresses this. Not the agent. The boundary. The tools it invokes. The services that provide those tools. The credentials that authorize access. Everything that sits between the governed agent and the external systems it acts upon.

Why Tool Governance Is Different

Traditional software interacts with tools and APIs through hardcoded integrations. A developer chooses the API, writes the integration code, reviews it in a pull request, tests it in staging, and deploys it to production. The tool surface is static. It changes only when a human changes it. Every integration is deliberate, reviewed, and versioned.

Agents fundamentally change this model.

Agents choose their own tools

In a traditional application, the developer decides at design time which APIs to call and under what conditions. The tool surface is a function of the code. In an agent system, the agent selects tools at runtime based on its current plan, context, and reasoning. The tool surface is a function of the agent's decisions.

This is not a subtle difference. It means tool selection is no longer a human design decision reviewed in code. It is an autonomous decision made by the agent at execution speed, potentially thousands of times per hour across a fleet. The set of tools an agent might call is not fixed at deployment. It depends on what the agent is trying to accomplish, what tools are available, and how the agent reasons about the best path to its goal.

The Model Context Protocol has made tool proliferation trivial. Connecting an agent to a new capability is as simple as pointing it at an MCP server. There is no integration code to review. No pull request to approve. No staging environment to test in. The agent discovers the tool's capabilities and begins using them.

An agent framework configured with 50 registered tools is functionally equivalent to giving an employee access to 50 enterprise systems. The question is whether any of those access grants were reviewed, scoped, time-limited, or even inventoried. In most organizations today, the answer is no.

Tool calls are trust boundary crossings

Every tool call is a trust boundary crossing. Data leaves the agent's governed context and enters an external system. The agent's identity, its authority grant, the policy evaluation that preceded the call: none of this is visible to the tool itself. The tool receives a request and processes it. It does not know whether the agent was authorized. It does not know whether the action aligns with the agent's declared intent. It does not care.

This is the fundamental asymmetry of ungoverned tool access. The governance system controls the agent, but the tool is outside the governance perimeter. Unless the governance architecture explicitly extends to the tool boundary, every tool call is an unmonitored exit point from the governed environment.

Consider what crosses the boundary. Input data flows from the agent to the tool. This data may include customer records, financial information, proprietary business logic, or credentials. Output data flows from the tool back to the agent, entering the agent's context and potentially persisting in governed memory. If the tool itself is ungoverned, there is no control over what data leaves, what data enters, or what the tool does with the data it receives.

Authority that does not extend to tool boundaries is incomplete authority. An agent that is authorized to "process insurance claims" but connects to ungoverned tools can, through those tools, access any system the tool credentials allow. The agent's authority is scoped. The tool's access is not.

Tools have their own risk profiles

From the agent's perspective, every tool invocation looks the same: send a request, receive a response. A read-only database query and a "delete all records" API call are both tool invocations. The agent's planning system treats them as capabilities with input parameters and expected outputs.

But the risk profiles are wildly different. A read-only query exposes data. A write operation modifies state. A destructive operation permanently alters or removes data. An external API call sends data outside the organization's boundary.

Without risk classification, every tool call receives the same governance treatment. The governance system has no mechanism to apply proportional controls. It cannot require human approval for destructive operations while allowing read-only queries to proceed autonomously. It cannot enforce data handling controls on external API calls while permitting internal queries without them. It cannot rate-limit high-risk operations more aggressively than low-risk ones.

An agent that can query a CRM and also send emails to customers illustrates the problem. Both are tool calls. Both are capabilities the agent might need. But querying the CRM retrieves internal data, while sending customer emails produces externally visible, potentially irreversible actions. Treating these two capabilities identically is not governance. It is the absence of governance.

Tool Registration and Access Control

The first requirement of tool governance is that every tool is known. An unregistered tool is an ungoverned tool. Registration is the foundation.

The Registration Requirement

Every tool that any agent can invoke must be explicitly registered before invocation is permitted. Registration is not a formality. It is the mechanism through which the governance system gains visibility and control over the agent's tool surface.

Registration captures: tool identity (a unique, verifiable identifier), tool owner (the team or individual responsible), capability declaration (what the tool does, expressed in terms the governance system can evaluate), risk classification (read-only, write, destructive, or external), access control requirements (which agents or agent classes are permitted to invoke it), rate limits (maximum invocations per time window), error handling behavior (what the tool returns on failure and what the agent should do), and data handling properties (what data the tool receives, what it returns, where it stores data, and retention policies).

This is the tool equivalent of Principle 1. Just as unidentified agents cannot operate in a governed environment, unregistered tools cannot be invoked. The principle is the same: you cannot govern what you have not identified.

The gap between this requirement and the current state of most agent deployments is significant. Most agent frameworks allow tools to be loaded at configuration time with no registration process, no review, no classification, and no access control. The tool exists. The agent can call it. That is the entire governance model.

Risk Classification

Not all tools are created equal. Risk classification enables the governance system to apply proportional controls, matching the rigor of governance to the severity of the capability.

Read-only tools (search, query, retrieve) are the lowest risk category. They do not modify state. The governance concern is data exposure: what data is the agent reading, and is it authorized to read it? A read-only query against a customer database is low risk from a state-modification perspective but may be high risk from a data-access perspective if the agent is not authorized to view the records it retrieves. Read-only tools receive standard logging and access control. The connection to Principle 8 is direct: data retrieved by read-only tools enters the agent's context and is subject to memory governance, including classification and retention rules.

Write tools (create, update) carry moderate risk because they modify state. Before a write tool executes, the governance system should verify that the agent's declared intent aligns with the write operation. An agent whose declared intent is "analyze customer data" should not be invoking a tool that updates customer records. Intent validation at the tool boundary catches misalignment between what the agent says it is doing and what it is actually doing. This is Principle 7 (runtime policy enforcement) applied specifically to tool invocations.

Destructive tools (delete, revoke, permanently alter) are high risk because their effects may be irreversible. This is where Principle 6 intersects with tool governance. Destructive tool calls should trigger human approval workflows by default. The control plane enforces this gate: when an agent's plan includes a destructive tool invocation, the governance system pauses execution and routes the action to a human reviewer before the tool call proceeds. The agent does not decide whether to seek approval. The architecture requires it.

External tools (third-party APIs, cross-boundary calls) carry elevated risk because the governance concern shifts from "what does this tool do" to "where does the data go." Data handling controls, egress policies, and contractual compliance become primary concerns. Is the third party a data processor under GDPR? Is the data allowed to leave the jurisdiction? Does the external service's privacy policy align with the organization's commitments to its customers? External tool governance is where tool governance meets data governance and regulatory compliance. For regulated industries, external tool calls may require not just technical controls but legal and compliance review as part of the registration process.

Access Control and Rate Limits

Registration makes tools visible. Access control determines which agents can use them.

Not every agent should have access to every registered tool. Tool access is governed by the same scoped authority model that governs other agent capabilities. An agent authorized to process insurance claims gets access to claims-related tools. It does not get access to the HR system, the financial ledger, or the infrastructure management API. The principle of least privilege applies to tool access just as it applies to data access and system access.

Rate limits provide a second layer of protection. An agent that calls a tool 10,000 times per minute is either compromised, buggy, or operating outside its intended parameters. Rate limits are a safety boundary that contains runaway behavior before it causes damage. They are particularly important for write and destructive tools, where rapid repeated invocation can cause significant harm.

Rate limits interact directly with Principle 10. Exceeding a rate limit should trigger fail-closed behavior, not silent degradation. The agent stops. The governance system logs the event with full behavioral context. An alert fires. The anomaly is investigated. This is the circuit breaker pattern applied to tool usage.

Usage logging feeds into the observability infrastructure from Principle 9. Every tool call is a behavioral event that must be captured with full governance context: which agent, what tool, under what authority, with what declared intent, at what lifecycle phase, and what the tool returned. This is not optional logging. It is the behavioral observability that makes tool governance auditable.

Error Handling as Governance

How a tool fails matters as much as how it succeeds.

A tool that returns an unhelpful error gives the agent an opportunity to improvise. The agent received an error. Its planning system determines an alternative approach. It tries a different tool, different parameters, a creative workaround. This is the exact problem that Principle 10 addresses: agents improvising through failures instead of failing closed.

Governed tools must have defined error semantics. The tool registration specifies what errors are possible, what each error means, and what the agent should do in response. A "permission denied" error means the agent lacks access and should not retry. A "rate limit exceeded" error means the agent should pause, not switch to a different tool that achieves the same result through an ungoverned path. A "service unavailable" error means the tool's backing service is down and the agent should escalate, not proceed without the data the tool was supposed to provide.

Error handling connects tool governance to the fail-closed semantic. A tool error is not just a technical event. It is a governance event. The governance system must ensure that tool errors produce governed responses, not creative workarounds that bypass the controls the tool registration was designed to enforce.

Trust-Gated Service Discovery

Registration governs individual tools. Service discovery governs the ecosystem of services that provide those tools. In environments where services deploy, scale, and retire continuously, the question is not just "is this tool registered" but "is the service providing this tool trustworthy right now?"

The Centralized Service Registry

A governed agent environment requires a centralized service registry: an authoritative catalog of available capabilities. Not "everything that is running on the network" but "everything that is approved, verified, and currently healthy."

We have written about the practical challenge of MCP discovery in enterprise environments. The problem is acute: agents need to find tools, but unmanaged discovery leads to agents connecting to whatever services they happen to encounter. The centralized registry solves this by becoming the single source of truth for what is available.

The registry functions as the service equivalent of the control plane. Just as agents do not access resources directly (they go through the control plane for authorization), agents do not discover services directly (they go through the registry for availability and trust verification). This mediation layer is what makes service discovery governed rather than ad hoc.

The boundary is hard: unregistered services are not invocable. An agent that discovers a service outside the registry, through network scanning, through a URL in its context, through a suggestion from another agent, cannot call it. The registry is not a recommendation engine. It is an enforcement boundary.

Trust State Management

Registration puts a service in the catalog. Trust state management determines what agents can do with it. Every service in the registry operates under one of four trust states, and the transitions between states are themselves governed.

Unverified. A newly discovered or newly registered service starts here. The service exists in the catalog, but it has not been reviewed or approved. Agents can see it. Depending on organizational policy, they may be able to invoke low-risk, read-only capabilities. Or they may not be able to invoke it at all. The point is that unverified services are visible but restricted. They cannot be used for sensitive operations, write actions, or anything that requires elevated trust.

Trusted. The service has passed organizational review. Its attestation has been verified. Its capability declarations have been validated. It operates under active governance with full monitoring. This is the steady state for production services. Agents can invoke any capability the service offers, subject to their own authority grants and the tool's risk classification.

Quarantined. The service has been temporarily suspended for investigation. Access is restricted to read-only or fully blocked, depending on the reason for quarantine. A service might be quarantined because behavioral observability detected anomalous patterns, because a health check failed, because a vulnerability was reported, or because an operator flagged a concern. Quarantine is the service equivalent of the circuit breaker from Principle 10: isolate the suspect component while investigation proceeds, without shutting down the entire system.

Revoked. The service has been permanently blocked. It may have been compromised, decommissioned, or determined to be untrustworthy. No agent can invoke it. The revocation is recorded in the audit trail. Revocation is terminal: a service that has been revoked must re-register under a new identity to re-enter the catalog, starting again at the Unverified state.

Transition rules matter. Unverified to Trusted requires explicit human review and approval. Trusted to Quarantined can be automated (triggered by observability alerts or failed health checks) or manual (triggered by an operator). Quarantined to Trusted requires re-review, with the quarantine reason resolved. Quarantined to Revoked is a governance decision with documentation. These transitions are auditable events, captured in the compliance observability layer.

Attestation and Capability Declarations

Trust requires verification. Services register with cryptographic proof of identity (attestation) that prevents impersonation. A malicious service cannot register as a trusted one because it cannot produce the correct attestation. This is the service equivalent of Principle 1: just as agents have verifiable identity, services have verifiable identity through attestation.

Capability declarations define what the service can do: what tools it provides, what inputs it expects, what outputs it produces, what data it accesses, and what side effects it has. These declarations are not aspirational. They are verifiable contracts. A service that declares "read-only database access" but modifies records in practice is in violation. The observability infrastructure from Principle 9 can detect this discrepancy by comparing declared capabilities against observed behavior. A service whose behavior deviates from its declaration should be automatically quarantined.

Lease-Based TTLs

Trust is not a permanent state. It is an active relationship that must be maintained.

Services registered in the catalog operate under lease-based time-to-live (TTL) windows that require periodic renewal. If a service fails to renew its lease, it automatically transitions out of the Trusted state. This prevents a common problem in enterprise environments: stale registrations lingering in service catalogs long after the underlying service has been decommissioned, replaced, or compromised.

TTL-based trust is the service equivalent of time-bounded authority from Principle 3. Agent authority expires and must be reissued. Service trust expires and must be renewed. Both mechanisms enforce the same governance principle: trust is not granted permanently. It is actively maintained through ongoing verification.

The practical implication is clear. A service that was deployed six months ago and has not renewed its registration is no longer trusted, even if it is still technically running and responding to requests. The governance system does not assume continuity. It requires proof.

Secrets Governance

Tools and services require credentials. Databases need connection strings. APIs need keys. Third-party services need OAuth tokens. In traditional systems, these secrets are managed by human operators, stored in vaults, and rotated on schedules. In agent systems, the agent needs the credential at execution time, autonomously, at machine speed.

The question is whether the agent holds the credential, or whether the governance system holds it on the agent's behalf.

Why Agents Must Never Hold Raw Credentials

An agent with a raw credential (an API key, a database password, a service account token) is an agent with unbounded, unauditable access to whatever that credential unlocks.

The credential is not time-bounded. It may be valid for months or years. The credential is not scope-locked. It grants whatever permissions the underlying account has, not just what the agent needs for its current task. The credential is not tied to intent. The agent can use it for any purpose, not just the one it was authorized for. In every dimension that Principle 3 defines for proper authority (explicit, scoped, time-bound), a raw credential fails.

The practical risks are significant. An agent with a raw database credential can query any table, not just the ones relevant to its current task. An agent with a raw API key for a cloud provider can provision infrastructure, not just query metadata. An agent with a raw email service credential can send messages to anyone, not just the intended recipients of its current workflow.

There is also the memory risk. Agents store context. If a raw credential enters the agent's context window, it may persist in session memory, in logs, or in shared state that other agents can access. The credential is no longer a secret. It is an artifact in the agent's memory, subject to whatever retention and access patterns govern that memory. Even with governed memory from Principle 8, the safest credential is one that never enters the agent's context at all.

Short-Lived, Purpose-Bound Capability Tokens

The alternative to raw credentials is purpose-bound capability tokens. Instead of receiving a credential that grants broad access, the agent receives a token that authorizes a specific action on a specific resource for a limited time. Four properties, all required.

Single-use. One action, one token. The token authorizes exactly one tool invocation. Once used, it is invalidated. This prevents replay (using the same authorization for a different action) and accumulation (collecting tokens for later use). An agent that receives a token to read customer record 8832 cannot use that token to read customer record 8833, or to read record 8832 a second time. Each invocation requires a new token, each issuance is a new governance decision.

Time-bounded. Short TTLs measured in minutes, not days. If the token is not used within its validity window, it expires. This limits the blast radius of a compromised token. Even if a token is intercepted, it is useless within minutes. Contrast this with a raw API key that remains valid until manually rotated, which in many organizations means months or years.

Scope-locked. The token is tied to a specific intent, goal, and delegation chain. It does not authorize "access to the CRM." It authorizes "read access to customer record 8832 for the purpose of processing claim 4491 under delegation chain from grant G-7720." This is Principle 3 realized at the credential level. The token carries the full governance context of the action it authorizes.

Audit-enriched. Every token issuance is a governance event recorded in the compliance observability layer. The record captures which agent requested the token, which action it authorizes, which human in the delegation chain authorized the agent to perform this action, and the stated reason. When an auditor asks "who accessed this data and why," the token issuance record provides the answer.

Break-Glass Access

Emergency scenarios exist. A production incident requires immediate access to a system. The normal token issuance process involves policy evaluation, authority verification, and potentially human approval. In a genuine emergency, this process may take too long.

Break-glass access provides immediate credential access for emergency situations. But it is not ungoverned access. Three mandatory controls apply.

First, mandatory audit logging. Every break-glass event is recorded with full context: who triggered it, when, for what purpose, and what systems were accessed. This record is immutable and cannot be modified after the fact.

Second, automatic alerts. Break-glass access immediately notifies security and compliance teams. The access is granted, but the organization knows it happened in real time. This enables rapid response if the break-glass access is inappropriate.

Third, mandatory post-incident review. Every break-glass event requires a formal review within a defined SLA. The review determines whether the emergency was genuine, whether the access was appropriate, and whether the normal governance process should be improved to handle similar situations without requiring break-glass in the future.

Break-glass is the secrets governance equivalent of the kill switch from Principle 10: a designed emergency mechanism with built-in accountability. Both exist because production systems encounter situations that normal processes do not cover. Both are governed by the principle that emergency access must be available but never unaccountable.

One critical signal: if break-glass access becomes routine, it indicates that the normal governance process is too restrictive or too slow for operational needs. Frequent break-glass usage is not a sign that the emergency mechanism is working. It is a sign that the standard process needs to be improved.

The Proxy Pattern

There is a practical adoption concern that every enterprise faces: how do you implement secrets governance without rewriting every agent and tool integration?

The proxy pattern provides the answer. Agents make standard HTTP requests through a governance proxy. The proxy handles credential injection (the agent never sees the raw credential), response scrubbing (removing sensitive data the agent does not need to retain), and allow-list enforcement (only approved endpoints and operations are reachable).

This achieves zero-code-change adoption. Existing agent code does not need to be modified. The governance boundary is external to the agent, consistent with the architectural principle from Principle 4 that governance enforcement lives outside the agent. The agent makes a tool call. The proxy intercepts it, injects the appropriate credential, forwards the request, receives the response, scrubs it, and returns the cleaned result to the agent. From the agent's perspective, nothing changed. From the governance system's perspective, every tool call is now mediated, credentialed, and auditable.

The proxy pattern also enables credential rotation without agent downtime. When credentials change, they change in the proxy configuration. Agents are unaware. No redeployment. No reconfiguration. No window of time where agents hold stale credentials. The rotation is invisible to the agent and immediate in effect.

What Happens Without Principle 11

Agents connect to ungoverned tools. Without tool registration, any tool in the agent's configuration is accessible. No risk classification. No access control. No usage logging. A tool that deletes production data receives the same governance treatment as a tool that queries a knowledge base: none.

Tool selection becomes a shadow IT problem. Without a centralized service registry, teams configure agents with whatever tool endpoints they find. Different agents use different services for the same capability. Nobody knows the complete inventory of tools in use. "Which tools do our agents have access to?" becomes an unanswerable question, and the answer changes every time someone deploys a new MCP server.

Trust is assumed, not verified. Without trust-gated discovery, agents connect to services based on configuration, not attestation. A compromised or misconfigured service is indistinguishable from a legitimate one. The agent has no mechanism to verify that the service it is calling is the service it thinks it is calling. A man-in-the-middle attack at the service layer is undetectable because trust was never verified in the first place.

Agents accumulate powerful credentials. Without secrets governance, agents hold raw API keys, database passwords, and service account tokens. These credentials are long-lived, broadly scoped, and unauditable. A compromised agent with raw credentials has the same access as the service account that issued them. The blast radius of a single compromised agent extends to every system those credentials unlock.

Credential leakage is undetectable. Without purpose-bound tokens, there is no way to determine whether a credential was used for its intended purpose. A credential used to read a single customer record looks identical in the logs to a credential used to export the entire customer database. The audit trail shows "credential used." It does not show "credential used appropriately."

Emergency access has no accountability. Without break-glass governance, emergency credential access is either impossible (leading teams to build permanent workarounds that bypass governance entirely) or ungoverned (leading to credential misuse during incidents with no audit trail and no post-incident review).

What Good Looks Like

• Every tool is registered with identity, owner, capability declaration, risk classification, access controls, rate limits, and error handling behavior. Unregistered tools cannot be invoked.
• Tools are classified by risk (read-only, write, destructive, external) and governance controls are proportional to the risk. Destructive tools require elevated approval. External tools require data handling controls and compliance review.
• A centralized service registry maintains the authoritative catalog of available capabilities. Agents discover services through the registry, not through configuration files or ad hoc endpoint lists.
• Services operate under trust state management with governed transitions: Unverified, Trusted, Quarantined, Revoked. Trust transitions are auditable and enforceable. Quarantine can be triggered automatically by observability alerts.
• Services register with cryptographic attestation and capability declarations verified against observed behavior. Registration uses lease-based TTLs that require periodic renewal. Stale registrations expire automatically.
• Agents never hold raw credentials. Access is mediated through short-lived, purpose-bound capability tokens that are single-use, time-bounded, scope-locked, and audit-enriched.
• Break-glass access exists for emergencies with mandatory audit logging, automatic alerts, and post-incident review. Break-glass frequency is monitored as a signal of process health.
• The proxy pattern enables zero-code-change adoption. Credentials are injected, responses are scrubbed, and allow-lists are enforced at the proxy layer. Credential rotation is invisible to agents.
• Tool usage feeds into the observability infrastructure from Principle 9, with full governance context on every invocation: which agent, what tool, under what authority, with what intent, and what the tool returned.

Where This Sits

Principle 11 is the fourth principle in Layer 3, Operations. Where Principle 8 governed persistent state, Principle 9 defined how the system is observed, and Principle 10 defined how the system behaves when things go wrong, Principle 11 governs what the agent connects to and under what conditions.

The relationship between Principles 10 and 11 is complementary. Safe failure defines how agents handle tool failures. Tool governance defines which tools agents can access in the first place and under what conditions. Principle 11 reduces the probability of the failures that Principle 10 contains. Fewer ungoverned tools means fewer ungoverned failures. Better error semantics at the tool layer means more predictable failure modes for the governance system to handle.

Principle 11 is required to reach Level 3 ("Governed") in the maturity model. Without tool and service governance, an organization can control individual agent behavior but cannot control what the agent connects to or what credentials it holds. The governance perimeter has a gap at precisely the point where agents interact with external systems.

The remaining principle completes the operational layer. Principle 12 (Multi-Agent Coordination) defines governance for agent-to-agent interaction. Together, Principles 8 through 12 ensure that agents are governed not just action-by-action, but operationally: in what they remember, how they are observed, how they fail, what they connect to, and how they coordinate with each other.

Principle 11 exists because an agent's capabilities are defined not by what it can reason about, but by what tools it can invoke. Ungoverned tool access is ungoverned agent behavior. If every tool is not registered, every service is not trust-verified, and every credential is not purpose-bound and time-limited, the governance architecture is incomplete at the point where it matters most: the boundary between the agent and the systems it acts upon.

---

This post covers Principle 11 from our whitepaper, 12 Non-Negotiable Principles for Agent Runtime Governance. The whitepaper defines all 12 principles across three layers (Foundations, Execution, and Operations) plus a 5-level maturity model and practical steps to get started. Download the full framework here.

If you missed earlier posts in this series: Principle 1: Agent Identity Is Mandatory, Principle 2: Explicit Purpose, Goals, and Intent, Principle 3: Authority Is Explicit, Scoped, and Time-Bound, Principle 4: Deterministic Control Planes, Principle 5: The Plan-Act-Observe Lifecycle, Principle 6: Human-in-the-Loop as First-Class Capability, Principle 7: Agent Runtime Policy Enforcement, Principle 8: Governed Memory and State, Principle 9: Observability and Auditability, and Principle 10: Safe Failure Semantics.

Need to design tool registration, credential brokering, and service governance for your AI agents? Our Authorization and Runtime Control Architecture workshop helps teams build the control infrastructure that governs what agents connect to and under what conditions. 1-2 days. Download the one-pager (PDF) or book a workshop.