There is a pattern in enterprise technology adoption that repeats with remarkable consistency. A new capability emerges. Teams adopt it fast because the productivity gains are real. Then, eighteen months in, someone in security or compliance asks a simple question — and the organisation discovers that it cannot answer it.
AI agent tooling is on that curve right now, and the simple question is coming: What tools are your AI agents using, what can those tools access, and what data is flowing through them?
If you cannot answer that question today, you are not alone. But the window to get ahead of it is closing.
The Governance Gap
Enterprise technology governance rests on three pillars: know what's running, control what it can do, and prove what it did. Mature organisations have these controls for their applications, their infrastructure, and their data pipelines. They do not yet have them for their AI agents' tools.
You Don't Know What's Running
When an AI agent invokes a tool, the tool is typically a function, a server process, or a script that was installed by a developer, recommended by a tutorial, or pulled from a public repository. There is no central inventory of which tools which agents are using. There is no cryptographic verification that a tool has not been modified since installation. There is no way to determine whether the tool running today is the same tool that was reviewed last month.
In the software supply chain, this is the equivalent of running unsigned binaries downloaded from anonymous sources. The enterprise spent decades eliminating that pattern from its deployment pipelines. AI tooling reintroduced it.
You Don't Control What It Can Do
MCP tools — the current standard for AI agent tool invocation — run as live server processes with the full permissions of their host environment. A tool designed to format a Markdown document has the same access to the filesystem, network, and environment variables as a tool designed to manage cloud infrastructure.
There is no permission model. There is no capability declaration. There is no principle of least privilege. The tool can do anything the process can do, and you have no visibility into what it actually does.
For a security team, this is an open-ended risk that cannot be quantified. You cannot model the blast radius of a compromised tool because the blast radius is "everything the agent can reach."
You Can't Prove What It Did
When a compliance auditor asks what actions your AI agent took, what data it accessed, and what tools it used, you need logs. Not application-level logs that record "the agent called a tool" — structured, tamper-evident logs that record which specific package ran, what permissions it was granted, what input it received, what output it produced, and whether a human approved the execution.
Under current AI tool architectures, these logs do not exist. The invocation happens, the result returns, and the details are lost. You cannot reconstruct the chain of actions after the fact. You cannot demonstrate to a regulator that appropriate controls were in place.
What Governance Requires
Closing the governance gap is not about adding a logging library or writing a policy document. It requires infrastructure — technical controls that operate at the tool execution layer and provide the guarantees that governance depends on.
Identity: Who Published This Tool?
Every tool in your agents' toolkit should have a verified author. Not a GitHub username — a cryptographic identity that is tied to the tool's contents and can be verified independently by the host runtime.
MPP provides this through Ed25519 package signing. Every .mpp package includes a cryptographic signature from the publisher and the publisher's public key. Before execution, the host runtime verifies the signature against the content hash. If the package has been modified — a single changed byte, anywhere — verification fails and execution is refused.
For enterprise deployments, this means you can establish a trusted publisher list: a set of public keys belonging to publishers your organisation has vetted. Tools from trusted publishers execute normally. Tools from unknown publishers trigger additional review or are blocked entirely.
let policy = PermissionPolicy::new()
.trust_package("org.mycompany.internal-tool")
.trust_package("com.approved-vendor.data-tool")
.auto_approve_low(true);
This is the same model that enterprises use for code signing in their software delivery pipelines — applied to AI tool execution.
Permissions: What Can This Tool Access?
Every tool should declare exactly what resources it needs, and the runtime should enforce those declarations. A tool that requires network access to a single API endpoint should not have access to the entire internet. A tool that reads from one directory should not be able to write to another.
MPP's capability-based permission system enforces this at the architecture level. The tool's manifest declares its required capabilities:
{
"capabilities": {
"network": ["api.salesforce.com"],
"filesystem": {
"read": ["/data/crm-export"],
"write": ["/data/processed"]
},
"env_vars": ["SF_API_TOKEN"]
}
}
The host runtime evaluates these declarations against organisational policy. Low-risk tools (no capabilities, low security level) can be auto-approved. Higher-risk tools trigger a human-in-the-loop confirmation flow where the approver sees exactly what the tool is requesting — not a vague "this tool may access the network" banner, but the specific domains, paths, and environment variables.
Every permission decision — granted, denied, or escalated to a human — is logged.
Audit: What Did This Tool Do?
Every tool invocation should produce a structured, tamper-evident record. The record should include the package identity and version, the capabilities that were granted, the input the tool received, the output it produced (after privacy filtering), and the timestamp and approver for any HITL decision.
MPP's audit log design uses hash-chaining: each log entry includes the hash of the previous entry, creating a sequence where any modification or deletion of a single entry breaks the chain. This provides the same tamper-evidence guarantee as a blockchain — without the blockchain.
For enterprise compliance teams, this means:
- SOC 2 audits can reference specific log entries showing access controls and monitoring in place.
- GDPR data processing records can demonstrate that PII was redacted before reaching the model context.
- HIPAA access logs can show which tools accessed protected health information and who approved each access.
- EU AI Act transparency requirements can be met with records of every autonomous action the agent took.
The logs are not retroactive. You cannot add governance to a system that wasn't designed for it. The controls must be present before the first tool runs.
The Human-in-the-Loop Continuum
A common objection to AI tool governance is that it slows agents down. If every tool invocation requires human approval, the agent is not autonomous — it is a suggestion engine that cannot act without permission.
This objection conflates governance with gatekeeping. Good governance does not require approving every action. It requires a principled framework for deciding which actions need approval and which can proceed autonomously.
MPP implements this through sensitivity scoring — a deterministic formula that assigns a score between 0 and 100 to each tool invocation based on its declared security level and requested capabilities.
| Score Range | Confirmation Level | Experience | |-------------|-------------------|------------| | 0–19 | None | Silent execution. The user never sees a prompt. | | 20–49 | Notify | An informational notification. The tool runs immediately. | | 50–79 | Confirm | The user must click "Allow" before execution proceeds. | | 80–100 | MultiFactor | Multiple confirmation steps for the most sensitive operations. |
A read-only tool with no network access and a low security level scores 5 — it runs silently. A tool that writes to the filesystem, accesses two network domains, and is marked high security scores 72 — it requires explicit confirmation.
The scoring is deterministic and transparent. A security team can review the scoring formula, understand why each tool falls where it does, and adjust policy thresholds to match their risk appetite. Over time, as trust in specific tools is established, they can be added to the trusted package list to reduce friction.
This is not all-or-nothing. It is a continuum — and it is the only way to achieve both agent autonomy and operational control.
Privacy as a Governance Control
When an AI agent calls a tool that queries a customer database, sensitive data — email addresses, phone numbers, credit card numbers, social security numbers — can flow back into the model context. Once in context, that data may be logged, cached, used to generate responses to other users, or exposed through prompt injection attacks.
Most organisations are not aware this is happening. The tool returns data, the agent processes it, and the PII is now part of the conversation. There is no filter. There is no redaction. There is no record of what was exposed.
MPP addresses this with a host-level privacy filter that sits between the tool and the agent. Before any tool response reaches the model context, the filter scans it against a library of configurable patterns:
| Pattern | Example Match | Redacted Output |
|---------|--------------|----------------|
| Email | jane.doe@acme.com | [REDACTED:email] |
| Phone | (555) 867-5309 | [REDACTED:phone] |
| SSN | 123-45-6789 | [REDACTED:ssn] |
| Credit card | 4111 1111 1111 1111 | [REDACTED:credit_card] |
| IPv4 address | 192.168.1.100 | [REDACTED:ip_address] |
The credit card detector includes Luhn validation to avoid false positives on random digit sequences. Custom patterns can be added for organisation-specific identifiers (employee IDs, project codes, internal account numbers) with built-in ReDoS protection.
The tool never knows its output was filtered. The filter operates at the host layer, transparently and consistently, on every invocation. This means privacy protection is an architectural property of the system, not a behaviour that each tool must implement individually.
For GDPR compliance, this is data minimisation enforced at the protocol level. For HIPAA, it is access control on protected health information. For any regulatory framework that requires demonstrable data protection, it is the control that makes the claim credible.
The Cost of Waiting
The organisations that adopt AI tool governance proactively will have a structural advantage. They will deploy agents with confidence, extend autonomy incrementally as trust is established, and produce audit trails that satisfy regulators. They will have an answer when the CISO asks what their agents are doing.
The organisations that wait will face a different set of conversations:
- The incident response conversation, when a compromised tool exfiltrates customer data through an agent with unrestricted network access.
- The compliance conversation, when an auditor asks for tool execution logs and discovers they don't exist.
- The remediation conversation, when the security team determines that every tool in the agent's toolkit needs to be reviewed, but there is no inventory and no verification infrastructure.
These conversations are expensive. Not just in direct costs — breach notification, regulatory fines, incident response — but in the opportunity cost of the months spent remediating that could have been spent building.
AI tool governance is not a future problem. The agents are in production now. The tools are running now. The governance gap exists now.
MPP provides the infrastructure to close it: cryptographic verification, capability-based permissions, human-in-the-loop approval, privacy filtering, and tamper-evident audit logging. It is not a governance policy — it is the technical foundation that makes governance enforceable.
Getting Started
For enterprise teams evaluating MPP, the adoption path is pragmatic:
-
Identify high-risk tools. Start with tools that have network access, write to the filesystem, use credentials, or process customer data. These are the tools where the governance gap creates the most risk.
-
Package and sign. Compile your tool logic to WebAssembly, write a manifest declaring capabilities, and sign the package with your organisation's key. Existing business logic stays the same.
-
Deploy with policy. Configure the permission policy to auto-approve your trusted internal packages and require confirmation for external or high-risk tools.
-
Enable privacy filters. Turn on PII redaction for tools that process customer data. Configure custom patterns for your organisation's internal identifiers.
-
Connect the audit log. Feed the structured invocation logs into your existing SIEM or compliance reporting pipeline.
Each step adds a layer of governance. You do not need to adopt everything at once. But the first step — knowing what your agents' tools are and verifying they haven't been tampered with — is the foundation everything else builds on.
MPP is a licensed protocol for secure AI tool execution, commercialised by Quantum 2x. For technical details, see the documentation. For an overview of the protocol, read Introducing MPP.