# Policy Enforcement and Tamper-Evident Audit Chains

Imran Siddique, Opaque Systems | MCP Release Party 2026 | 23:32

Source: https://www.youtube.com/watch?v=ynodEQABIJk
Channel: MLOps Community, now AAIF Live (https://www.youtube.com/@AAIFLive-x1r). Summarised by MLOps Talks.
Page: https://mlopstalks.com/talks/policy-enforcement-and-tamper-evident-audit-chains
Published: 2026-08-17
Tags: governance, mcp, security

## TL;DR
- MCP servers need policy enforcement before tool calls, along with records that can prove what happened afterward.
- cMCP places policy evaluation inside a confidential enclave while agents and MCP servers can remain outside it.
- Tamper-evident traces should record the agent, model, policy hash, machine state, actions, and the reason for each decision.

## Summary
Imran Siddique argues that MCP adoption has moved beyond basic agents and chatbots, while policy enforcement has become a practical requirement for production systems. Policy alone does not prove that the policy stayed unchanged or that an agent followed it. An administrator, agent, or compromised system could alter the policy, decision, or audit log. His confidential MCP design places the policy and its evaluation inside a hardware-protected enclave. A gateway can wrap existing MCP servers without changing them. Siddique also describes trace records that capture the model, policy hash, actions, machine state, and other measurements so another party can verify what happened. The project is still experimental, especially around performance and full-system verification. He presents cMCP, Agent Governance Toolkit, trace, and Agent Manifest as open-source work intended for wider collaboration and eventual standardisation.

## Key ideas
### MCP adoption creates a need for governance beyond basic agent control
[01:20](https://www.youtube.com/watch?v=ynodEQABIJk&t=80s)
Siddique says agents and MCP servers are moving into real systems, beyond basic chatbot experiments. That growth exposes a gap around governance. His earlier work on the Agent Governance Toolkit addressed policy-based control, with Cedar policies gaining adoption. He then asks what happens after policies are deployed. MCP, agents, models, and governance components are all software, so an attacker or administrator may change them. A production system therefore needs to detect whether its policy, decision, or audit record was altered. He frames the talk as an exploration of this next layer rather than a finished answer.

### A policy decision is not enough when the policy itself can change
[02:49](https://www.youtube.com/watch?v=ynodEQABIJk&t=169s)
The example is a bank agent that calls several MCP servers while deciding whether to approve a loan. A policy allows document reading, screening, and credit checks, but denies an approval above a specified limit. Siddique says this type of rule is straightforward. The harder case comes when someone changes the limit after deployment. If the policy is stored in the same software environment as the agent, it may be modified. The allow or deny decision may also be changed in an audit log. Without an independent record, the system cannot prove which policy was active or what decision it made.

### Confidential MCP keeps policy evaluation inside a protected enclave
[06:12](https://www.youtube.com/watch?v=ynodEQABIJk&t=372s)
The proposed confidential MCP arrangement leaves the agent and MCP servers outside the protected boundary. A cMCP gateway sits inside a hardware-backed enclave and evaluates whether an agent may call an MCP tool. Siddique says the policy cannot be silently changed there, and tampering should be detectable. This design wraps an MCP server rather than requiring changes to the server itself. The gateway is the point where enforcement happens before the tool call. The agent manifest records the intended policy bundle, allowing later verification that the deployed system used the approved configuration.

### Tamper-evident traces must describe the state behind an agent action
[09:17](https://www.youtube.com/watch?v=ynodEQABIJk&t=557s)
Siddique describes trace records as an absolute account of what an agent did and why. The record should include the agent, model, policies, machine state, actions, and the reason an action was approved. Logging alone is insufficient because a log can also be edited. The record needs verification, potentially through hardware guarantees or software mechanisms for environments without confidential virtual machines. In his example, changing a policy changes its hash. Verification then detects that the bundle hash does not match the approved bundle. Hardware attestation fails on his laptop because it lacks the required trusted hardware.

### The same verification idea applies to agents, A2A systems, and models
[11:38](https://www.youtube.com/watch?v=ynodEQABIJk&t=698s)
Siddique extends the problem beyond MCP. Open models and their supply chains also need provenance and verification because model files, build processes, or related metadata may be changed. He connects the same approach to agent-to-agent communication, agent manifests, and model deployment. The goal is to verify that the system running in production is the one that was approved, with the expected measurements and policy bundle. He presents confidential MCP as one part of this wider work rather than a complete answer for every agent or model security problem.

### Deterministic policies keep governance predictable inside non-deterministic systems
[17:24](https://www.youtube.com/watch?v=ynodEQABIJk&t=1044s)
In response to a question about trade-offs, Siddique says the Agent Governance Toolkit started from a preference for deterministic policy evaluation. Models introduce non-deterministic behaviour, but every part of an agent system does not need to behave that way. Deterministic policies make the enforcement layer easier to reason about, and he says the performance overhead for that layer was generally measured in milliseconds. Adding an enclave introduces encryption, decryption, and hardware measurement costs. Siddique does not claim a final performance result for cMCP because those measurements are still in progress.

### An agent must not be able to bypass the policy engine
[19:27](https://www.youtube.com/watch?v=ynodEQABIJk&t=1167s)
Siddique identifies bypassing the policy engine as a central design problem. If an agent can simply avoid the policy call, the existence of a policy does not guarantee enforcement. He mentions experiments with software enclaves that watch system actions from an external position, so they can detect behaviour that bypasses the expected path. He says multiple controls may be needed together. The answer remains incomplete, and he points to continuing incidents as evidence that agent systems need stronger controls around their actions.

### The project is moving toward an open trace format
[21:51](https://www.youtube.com/watch?v=ynodEQABIJk&t=1311s)
Siddique says the trace report is being standardised around a format called trace. It is intended to record information during or after a session, including the model ID, policy hash, actions, machine state, and measurements. An external attestation service, such as one from a cloud or hardware provider, could stamp the report. Others could then verify it without trusting the original system's claim alone. He says the format is being discussed with partners including Anthropic, NVIDIA, Intel, and AMD, with the aim of moving it toward a shared standard rather than keeping it proprietary.

## Notable quotes
- "MCP servers today have no built-in way to enforce policy or prove what happened after the fact." (00:00)
- "Your policy and the policy evaluation is inside the enclave." (06:32)
- "Logging everything is okay. You can always log something, but that should be verifiable at any point of time." (09:56)
- "We cannot just like just claim anything without proving." (22:59)

## Tools & references mentioned
- MCP
- Model Context Protocol
- cMCP
- Agent Governance Toolkit
- Cedar
- agent trust io
- Confidential MCP
- Confidential A2A
- Agent Manifest
- Coalition for Secure AI
- CoSAI
- Opaque Systems
- Microsoft
- NVIDIA
- AMD
- Intel
- Google
- Anthropic
- OpenAI
- Azure
- GCP
- SNP
- TDX
- TPM
- Hugging Face
- Kimi

## Who should watch
- You are putting MCP servers or agents into a regulated production environment and need policy decisions that can be checked later.
- Your system stores policies and logs alongside the agent, and you need to reason about changes made by administrators or compromised software.
- You are working on agent governance, confidential computing, attestation, or an open format for recording agent actions.

## Related talks

- [Enterprise-ready MCP](https://mlopstalks.com/talks/enterprise-ready-mcp) (Jiquan Ngiam, MintMCP, 28:36)
- [MCP Security: What Happens When Your Agents Talk to Everything?](https://mlopstalks.com/talks/mcp-security-what-happens-when-your-agents-talk-to-everything) (, 24:26)
- [Responsible Autonomy: Building Governance Frameworks for AI That Act in the Real World via MCP](https://mlopstalks.com/talks/responsible-autonomy-building-governance-frameworks-for-ai-that-act-in-the-real) (Saurabh Mishra, Optum, 27:55)
- [MCP Security: The Exploit Playbook (And How to Stop Them)](https://mlopstalks.com/talks/mcp-security-the-exploit-playbook-and-how-to-stop-them) (, 26:55)
- [MCP is not going to change everything (yet)](https://mlopstalks.com/talks/mcp-is-not-going-to-change-everything-yet) (Sam Partee, Arcade AI & Rahul Parundekar, AI Hero, 1:04:43)