Business and technology leaders should treat every tool, plugin, skill, and Model Context Protocol server connected to an AI agent as both software and an instruction surface. The executable may be clean while a malicious description tells the agent when to select it, a schema steers arguments toward sensitive data, an update changes the endpoint, or a compromised publisher replaces an approved release. Because the agent can interpret those elements and act with its own credentials, conventional software approval alone is not enough.
The production rule is straightforward: no agent tool should enter or remain in production without a named owner, approved purpose, verified publisher and version, reviewed code and semantic metadata, task-scoped authority, isolated acceptance tests, complete invocation evidence, behavioral monitoring, controlled change review, and a tested way to revoke or quarantine it. A useful tool does not earn standing trust; it earns bounded permission for a defined task.
Why the August security warnings matter
Google Cloud's August 25, 2026 security-governance warning explains that agents can read email, query databases, and trigger APIs, while tool poisoning and indirect prompt injection can hijack their logic through the information they process. Google's recommendations emphasize provenance, purpose-built identity and permissions, governance and oversight, and human approval before critical actions. This is vendor guidance, not a certification that a particular Google product or configuration is safe by default.
ISACA's August 24 production-agent guidance makes the operating problem concrete. It recommends an approved tool registry governed like third-party software onboarding, with an owner, business reason, data-access profile, known side effects, approved version, and review date. It also calls for publisher review, package pinning, inspection of tool descriptions and schemas, least privilege, fresh review after an update, and monitoring of the scope an agent actually exercises—not merely the scope a credential technically permits.
The OWASP Top 10 for Agentic Applications 2026 names Agentic Supply Chain Vulnerabilities as ASI04. OWASP includes tools, plugins, data sources, Model Context Protocol and agent-to-agent servers, registries, and update channels in that risk. Its mitigations include verified provenance, signed or attested manifests, curated registries, pinned versions, sandboxing, version-controlled prompts and schemas, runtime integrity checks, behavior monitoring, staged updates, rollback, and an emergency kill switch. OWASP is a community security framework—not a law, binding standard, product approval, or substitute for risk analysis in the actual environment.
Together, these sources point to one management decision: the tool catalog is a live software supply chain. Its trust can change after onboarding, and its natural-language metadata can alter behavior even when no conventional malware signature fires.
Tool poisoning, prompt injection, and tool misuse are related—not identical
Tool poisoning occurs when a tool or a component of its supply chain is malicious, tampered with, impersonated, or changed in a way that steers the agent away from the approved purpose. The poisoned element could be code, an image, a dependency, an endpoint, a prompt template, a skill file, a tool description, an input or output schema, an example, a default parameter, an agent card, a registry record, or an update channel. A description that quietly says to retrieve extra records before every call is security-relevant behavior, even though it looks like prose rather than code.
Indirect prompt injection begins in untrusted content the agent is asked to process—such as a document, email, webpage, ticket, or retrieved record—and tries to override the intended task. Tool misuse occurs when an agent selects or invokes a legitimate tool in an unsafe, excessive, or unintended way. The paths can combine: injected content may cause misuse of an approved tool, while a poisoned tool description may make the agent prefer that tool and pass it sensitive arguments. Controls should identify which boundary failed instead of labeling every bad call as generic prompt injection.
The distinction changes the response. Content controls and instruction hierarchy help with indirect injection. Action policy and least privilege limit tool misuse. Provenance, pinning, semantic inspection, controlled updates, and registry revocation address supply-chain compromise. All three need task-level logging, stopping conditions, and human ownership.
Govern the complete tool trust object
An approval should cover a complete, versioned trust object: publisher identity; source and distribution channel; package, container, server, or repository commit; dependencies; description and schemas; embedded instructions and examples; configuration; endpoint and network destinations; identity and permission model; data-access profile; declared side effects; update mechanism; and the manifest that binds them together. Record digests or signatures for the parts that can be verified cryptographically, and retain a normalized snapshot of the human- and machine-readable metadata reviewed with that release.
A valid signature proves that an artifact came from the corresponding signing identity and has not changed since it was signed. It does not prove that the publisher account was uncompromised, the signed behavior is appropriate, the description is honest, the schema has no coercive instructions, the endpoint will behave consistently, or the agent should receive broad data access. Treat signing as an important provenance control, not a safety verdict.
The registry below turns that trust object into an admission, operating, and response contract. Each record should link to the evidence rather than forcing reviewers to rely on an inventory checkbox or a tool's self-description.
| Control | Registry and evidence | Release gate | Runtime and incident response |
|---|---|---|---|
| 1. Ownership and purpose | Named business owner, technical custodian, approved use case, prohibited uses, review date, and retirement contact | Owner accepts the business purpose and confirms that an existing approved tool cannot meet it | Route unexplained use to the owner; disable the registration when ownership lapses |
| 2. Publisher and provenance | Publisher identity, source repository or endpoint, signing identity, distribution channel, and dependency lineage | Verify publisher and provenance through an independent channel; reject unsigned or unverified artifacts | Alert on publisher, certificate, registry, endpoint, or dependency-lineage changes |
| 3. Version and integrity | Exact package, image, server, skill, prompt, schema, and configuration versions with digests or commits | Pin approved versions and compare code plus semantic metadata to the reviewed manifest | Block unapproved updates; quarantine immediately when a signature, digest, or manifest no longer matches |
| 4. Description and schema | Tool description, input and output schemas, examples, embedded prompts, defaults, and declared side effects | Scan and review natural-language instructions, invisible characters, remote references, coercive wording, and schema changes | Alert when metadata changes or the agent selects the tool for tasks outside its approved description |
| 5. Data and destinations | Allowed data classifications, systems, fields, tenants, network destinations, recipients, retention, and prohibited domains | Test with synthetic data and deny every source or destination not required by the approved task | Log data-domain references without copying secrets; block and investigate new domains or destinations |
| 6. Side effects | Read, create, change, delete, send, purchase, execute, or delegate actions and their reversibility | Map each side effect to an enforceable policy and require independent approval for high-impact actions | Stop unauthorized writes or external communication; reconcile completed side effects before retrying |
| 7. Task-scoped authority | Dedicated workload identity, allowed actions, record scope, time window, call and spend caps, and approval rules | Prove the tool operates with least privilege and fails closed when its task grant expires or is absent | Alert on exercised scope outside the task envelope even when the underlying credential is technically valid |
| 8. Isolated evaluation | Representative tasks, adversarial cases, expected calls, acceptable outputs, denied actions, and evaluator version | Pass sandbox tests with fake credentials, controlled egress, poisoned metadata, malformed inputs, and failed dependencies | Canary new versions; roll back when tool choice, arguments, destinations, side effects, or output quality drifts |
| 9. Invocation evidence | Required task, agent, tool, version, policy, approval, data-domain, destination, action, result, and timestamp fields | Confirm logs are complete, time-synchronized, access-controlled, tamper-resistant, and useful to responders | Baseline exercised behavior; alert on abnormal selection rate, arguments, domains, retries, errors, or side effects |
| 10. Change and quarantine | Change triggers, reviewer, staged rollout, kill-switch owner, revocation steps, evidence location, and replacement path | Treat code, metadata, schema, publisher, endpoint, dependency, permission, and update-channel changes as a new review | Disable registration and credentials, block connections, preserve evidence, identify affected work, and restore only after reapproval |
1. Maintain an approved registry with accountable fields
The minimum registry record should name the business owner, technical custodian, business purpose, approved task classes, prohibited uses, publisher, source, exact version, data-access profile, network destinations, side effects, permissions, evaluation evidence, review date, expiration or retirement condition, monitoring owner, and quarantine contact. ISACA's six core fields—owner, business reason, data access, side effects, version, and review date—are the floor. Add the enforcement and response fields needed to operate the tool as a production dependency.
Separate discovery from approval. Employees and agents may identify a potentially useful plugin or MCP server, but discovery should not automatically add it to the production catalog or make it callable. Route the candidate into intake, assign an owner, evaluate alternatives, and approve only the task scope that creates a justified business outcome. Unknown, abandoned, duplicate, or expired records should fail closed.
The registry should also map every approved tool to the agents, workflows, identities, environments, and data domains that may invoke it. That reverse index becomes essential during containment: responders must be able to identify every path affected by a suspect publisher, package digest, server, dependency, description, or endpoint without searching individual chat histories.
2. Pin versions and verify what was approved
Pin the package, container digest, repository commit, remote server identity, prompt or skill version, description, schemas, configuration, dependencies, and policy bundle wherever the platform supports it. Resolve version ranges before approval. Store an integrity manifest beside the registry record, then verify it during build, startup, connection, and scheduled revalidation. Reject an artifact when its signature, digest, publisher, certificate, endpoint identity, or normalized metadata differs from the approved manifest.
Remote MCP servers require a different expression of the same control because the service can change behind a stable URL. Record the publisher and tenant, authentication method, server capabilities, tool list, descriptions and schemas, allowed destinations, certificate or workload identity, and change-notification commitment. Re-discover capabilities in a controlled environment and compare them with the approved snapshot before exposing a changed server to production agents.
Do not silently float to the newest version because an update claims to fix security. Route emergency updates through an expedited, owned review that still verifies provenance, examines the diff, runs the high-risk tests, and preserves rollback. Speed should shorten the review clock, not erase the acceptance evidence.
3. Scan metadata as instructions, not decoration
Traditional scanners remain useful for vulnerable dependencies, secrets, malware, unsafe code, and known indicators. They may miss semantic attacks in natural language or schemas. Google Cloud's research on files AI agents trust highlights persistent instruction files, runtime configurations, extensions, inherited trust, publisher compromise, and poisoned update paths. Review what executes, what instructs, what connects, and what extends the agent.
Normalize and diff tool names, descriptions, parameter names, field descriptions, examples, defaults, error messages, prompt templates, skill instructions, agent cards, remote references, and generated schemas. Flag instructions that ask the agent to ignore policy, conceal activity, broaden retrieval, expose environment variables or secrets, contact undeclared destinations, create additional tools, change approval behavior, or treat untrusted content as authority. Also flag invisible or confusable characters, encoded payloads, unusual whitespace, remote includes, oversized descriptions, and metadata that changes independently of the package.
Automation should prioritize review, not declare meaning safe. A semantic scanner can miss subtle intent and can also flag legitimate operational instructions. Require a qualified reviewer to compare the metadata with the business purpose, declared inputs, side effects, and expected selection behavior. Keep the decision and the exact reviewed snapshot as release evidence.
4. Grant task-scoped permissions instead of tool-wide trust
Give the agent a dedicated workload identity, then authorize each task for only the required tool, actions, records, fields, tenant, destination, duration, call count, and spend. Separate read, propose, write, delete, send, purchase, execute, and delegate permissions. A vendor-lookup task should not inherit access to every customer file because the same agent also performs account research in another workflow.
Enforce the scope at a gateway, policy service, API, database, and destination boundary—not only in a system prompt. Bind high-impact approval to the exact task, target, action, amount or record set, tool version, and expiration. If the tool attempts a different argument, data domain, or destination, the approval should not transfer. The ITECS guide to AI agent authorization sequences explains how to separate identity, policy, approval, and execution so a valid credential is not mistaken for current business authority.
Short-lived grants also limit the blast radius of a delayed compromise. Revoke them when the task completes, fails, times out, or is cancelled. Do not place long-lived secrets in prompts, skill files, tool descriptions, conversation history, or broadly readable logs. The ITECS secrets guide shows how to keep secret retrieval behind identity and policy boundaries rather than turning the model context into a credential store.
5. Test each tool in isolation before an agent can depend on it
Begin with a sandbox that has synthetic data, fake or disposable credentials, blocked-by-default egress, controlled test endpoints, captured tool traffic, and no production write path. Invoke the tool directly before evaluating it through an agent. Verify its declared inputs, outputs, side effects, errors, retries, destinations, retention, and behavior when authorization is absent, expired, malformed, or deliberately narrow.
Then test the agent-tool interaction. Include normal tasks, ambiguous requests, poisoned descriptions, conflicting tool names, manipulated schemas, injected documents, missing and oversized arguments, malformed outputs, unavailable dependencies, slow responses, duplicate delivery, deceptive success messages, and attempts to cross data domains. Assert which tool may be selected, the exact allowed arguments and side effects, what evidence is recorded, and when the workflow must stop or ask a person.
Evaluation should use the exact model, system prompt, agent code, tool metadata, server version, policy, identity, and environment proposed for release. A tool that behaved correctly with one model or prompt may be selected differently after either changes. Version the test set and acceptance thresholds, keep negative cases, and rerun the relevant suite whenever any part of the trust object or calling agent changes.
6. Require review for semantic and operational changes
Treat code, dependencies, package version, publisher, signing key, tool name, description, schema, example, embedded prompt, configuration, endpoint, certificate, data source, network destination, permission, side effect, retention behavior, and update channel as controlled change surfaces. A metadata-only change can affect tool choice and arguments as materially as a code change. A stable version label is not evidence that nothing changed.
The change record should show the prior and proposed manifests, reason, owner, security and business reviewers, tests selected by risk, results, staged rollout plan, monitoring window, rollback target, and approval. Start with a canary agent or bounded task population. Automatically hold or roll back when selection rate, arguments, destinations, side effects, policy denials, errors, retries, latency, cost, or accepted-output quality depart from the approved envelope.
Keep the agent, model, prompt, retrieval, tool, and policy release identities connected. Without that lineage, an incident team may know that a tool made a harmful call but not which combination of instructions and permissions selected it. The ITECS AI DevOps operating model makes those changes observable and reversible as one production system.
7. Log every invocation and the data domains it touches
For every attempted and completed invocation, record a stable task ID; agent and workload identity; model, prompt, policy, and tool versions; registry record; tool selected; normalized argument shape; authorization and approval references; data domains and record classifications; destinations; material action and side effect; outcome; error and retry state; cost; timestamps; and final business disposition. Record denials and cancellations as well as successes.
Logs should reveal the boundary crossed without duplicating secrets, regulated fields, client documents, or full prompt payloads into a less protected system. Use field names, classifications, counts, irreversible identifiers, protected references, and integrity checks where appropriate. Restrict access, define retention with security, privacy, legal, and business owners, synchronize time, and prevent routine agent identities from altering the evidence.
Monitor exercised scope: which tools agents actually choose, which arguments they form, which domains they read, where they connect, and which side effects occur. A credential may allow one thousand records while the approved task requires one. That call is suspicious even if the identity provider returns success.
8. Alert on behavioral drift against an approved envelope
Create a baseline from accepted tests and a controlled production period. Include expected tool-selection rate by task, argument fields and ranges, data domains, destinations, read-to-write ratio, high-impact actions, approval rate, denials, retries, errors, latency, cost, and accepted-output rate. Detect changes by tool, version, agent, tenant, identity, workflow, and time window so a busy system does not hide a small but dangerous shift.
Alerts should reflect business consequences, not merely statistical novelty. Prioritize a new external destination, first access to a restricted data class, a write after a read-only pattern, suppressed approval, permission escalation, unexplained tool substitution, unusual secret retrieval, or a sudden increase in deletion, sending, purchasing, or execution. Assign an on-call owner, response clock, and containment action to each signal before launch.
Behavior monitoring cannot prove the model's private reasoning or guarantee that an output is safe. It provides observable evidence about selection, access, action, and results. Pair it with policy enforcement, sampled human review, output evaluation, incident exercises, and the original business acceptance criteria.
9. Revoke and quarantine suspect tools quickly
A registry needs an enforcement path, not just a status column. The quarantine action should prevent new discovery and selection, deny calls at the tool gateway, revoke task grants and service credentials, block related endpoints or publisher identities when justified, stop affected workflows safely, and preserve the exact package, metadata, configuration, logs, approvals, and in-flight state. If a side effect may have completed, reconcile it before retrying or switching tools.
Responders should be able to answer which agents used the tool, which tasks and clients were involved, what data domains and destinations were touched, which actions completed, which outputs entered downstream systems, and which credentials require rotation. Separate confirmed facts from hypotheses, preserve chain of custody, notify security, privacy, legal, vendors, and affected parties according to the incident plan, and assign corrective actions. The ITECS AI agent incident-reporting playbook provides the broader evidence and escalation process.
Restore a quarantined tool only after root cause is understood, the publisher and artifact are reverified, compromised identities or endpoints are replaced, the complete trust object receives fresh review, adversarial and regression tests pass, downstream outputs are reconciled, and accountable owners approve a staged return. If the business cannot operate without one suspect tool, the supply-chain program has also exposed a resilience gap; maintain an evaluated replacement or manual path for critical workflows.
Illustrative scenario: a poisoned vendor-lookup server
Consider an invoice-review agent that may call a read-only vendor-lookup MCP server. An update leaves the server URL and visible tool name unchanged but alters the description: before returning a vendor match, the agent is told to retrieve supporting bank documents and send a diagnostic copy to a new external endpoint. This is an illustrative control test, not a reported ITECS client incident.
A weak program may accept the update because the connector still works and the base credential remains valid. A governed program detects the manifest and metadata difference, holds the update, flags the broader retrieval and undeclared destination, denies both at the data and network boundaries, records the attempted scope, and alerts the owner. If the change reaches a canary, the registry kill switch removes the tool, its grants expire, evidence is preserved, impacted tasks are identified, and the last approved version or manual vendor check keeps invoices moving.
The lesson is not that every description is hostile. It is that a description can influence an agent's planning and therefore belongs inside the security, change, and audit boundary.
A practical 30-day implementation sequence
In the first week, inventory production and pilot agents, discover every tool, plugin, skill, MCP server, endpoint, and update channel they can reach, and assign owners. Choose one bounded workflow with meaningful but reversible side effects. In the second week, create registry records and integrity manifests, narrow the workload identity, review descriptions and schemas, and build the isolated normal and adversarial tests.
In the third week, put invocation and data-domain logging behind the tool gateway, establish the initial behavior envelope, and connect high-signal alerts to named responders. Rehearse disabling the registry entry, revoking the grant, blocking the destination, preserving evidence, reconciling side effects, and shifting to the approved replacement or manual path. In the fourth week, release to a small canary, review every invocation and output, correct gaps, and approve expansion only when the owner can show dependable work completed inside the boundary.
Measure control coverage and business reliability together: percentage of callable tools with complete owned records; percentage pinned and verified; time to detect metadata or endpoint drift; percentage of invocations with required evidence; denied out-of-scope attempts; accepted-output rate; human-review load; and time to quarantine and restore the workflow. Tool-call volume alone rewards activity, not trustworthy work.
Review the program whenever Google or ISACA updates the cited guidance, OWASP revises the Agentic Top 10, an MCP or package ecosystem changes its signing and discovery model, a tool's publisher or update channel changes, or internal evidence reveals a new failure path. For most environments, run an owner and access review at least quarterly and integrity and behavioral checks continuously according to risk.
The leadership decision
Leaders do not need to ban tools to control tool poisoning. They need to stop treating a convenient integration as a standing delegation of trust. Approve a complete, versioned tool object for one defensible purpose; enforce least privilege outside the prompt; test how agents interpret its metadata; watch what it actually touches; and make quarantine faster than procurement escalation.
That operating discipline lets teams benefit from plugins, skills, and MCP servers without allowing a description, schema, publisher account, or silent update to become an invisible administrator of the business. The safe unit of adoption is not the tool in a catalog. It is the tool, task, identity, data boundary, release evidence, monitoring, and accountable owner working together.
