DEV Community: Imran Siddique

Soon There Will Be More Agents Than Users. Here Is the Trust Layer That Makes That a Good Thing.

Imran Siddique — Thu, 30 Jul 2026 00:52:56 +0000

A map of where the internet of agents is heading, the work I have been doing one layer ahead of it, and how we get to a future you can actually trust.

In a few years, most of the meaningful activity on the internet will not be people clicking. It will be agents acting. Booking, negotiating, filing, reconciling, buying, delegating to other agents, all on our behalf, across the boundaries between companies that have never met.

I think that future is good. I have spent the last stretch of my career building toward it on purpose. But it only works if we get one thing right, and it is the thing almost no one is building yet.

Agents need what people and services already have: provable trust.

The gap nobody had to think about, until now

Every serious actor on the internet already carries verifiable trust. A person has an identity and credentials. A service has a certificate. An API call carries a signed token. A container has a digest. A machine has a hardware root. We spent thirty years building that fabric, and it is the reason you will put your credit card into a web page you have never visited. TLS and certificate authorities did not make the web safe by scaring people. They made commerce possible by making trust verifiable.

Agents have none of that yet. An agent today can authenticate, but it cannot prove what it is, what it was allowed to do, or what it actually did, to anyone who does not already trust its operator. For a chatbot, that does not matter. For an agent moving money, touching patient records, or delegating a task to another company’s agent, it is the whole game.

So, the internet of agents needs its own trust layer. Not guardrails bolted on after the fact. A native fabric of identity, authority, and provenance that any third party can verify without taking anyone’s word for it.

That fabric is what I have been building, and I have been building it one layer ahead of where the conversation was.

The path so far, and why each step came early

Here is the honest sequence, because the map matters more than the milestones.

Enforcement, while the industry was still filtering tokens. Running eleven agents in production against real systems taught me the thing most safety tooling misses: the danger is not what a model says, it is what an agent does. A jailbreak detector sees no jailbreak when an agent simply executes a tool call that wipes a database. So, I built the Agent Governance Toolkit to govern the action itself, every tool call intercepted and evaluated against declarative policy before it runs, deterministic and fail-closed, covering all ten of the OWASP Agentic risks by design. When AGT shipped, the category itself was still the news. That was the point. The enforcement layer had to exist before anyone could see it was missing.

Naming the trust gap before the protocols admitted it. As MCP and A2A won the transport war, I said plainly what they left out. The parts of AGT that became AgentMesh were built as the trust layer those protocols do not provide. Identity, delegation, and provenance for agents, because the transport layer was never going to supply them.

Pointing at the seam, and watching the field converge on it. Enforcement gets you policy and a tamper-evident log. It does not give you the decision itself as a sealed artifact that an outside party can verify without trusting the operator who produced it. I flagged that seam in the open. What happened next is the part I find most telling. Independent builders across the community converged on the same primitives to close it: canonical hashing, pre-execution sealing, offline verification, and an anchor that belongs to no single operator. When that many people build toward the same point on a map, the map is real.

Formalizing the convergence into open standards. That is what the agentrust-io specifications are. Agent Manifest gives an agent a provable identity across its ten trust surfaces. TRACE turns a decision into hardware-rooted evidence anyone can verify offline. Confidential MCP enforces policy where neither the operator nor a compromised dependency can reach it. cA2A carries all of it across the boundary between agents. Four specs, one idea: turn “trust us” into “verify it yourself.”

Building the substrate underneath. A policy engine is only as trustworthy as the ground it runs on. That is why the next layer is hardware, and why the work now sits on a confidential-computing substrate that proves the governance held. Enforcement, evidence, and the silicon that anchors both.

Each of those steps looked early when I took it. None of them looks early now. That is usually how you know you were reading the road correctly.

Where the path goes next

I would rather show you the horizon than sell you the current milestone, so here is where I think this goes.

Agents get portable, verifiable reputations. Once an agent can prove what it is and what it did, it can carry that proof between organizations. An agent that has behaved correctly under attested policy for ten thousand transactions is a different counterparty than one with no history, and soon you will be able to tell the difference cryptographically, not by trusting a logo.

Delegation becomes an economy. When authority can be attenuated and proven at every hop, agents can safely hand work to other agents across company lines. That is the unlock for an actual agent-to-agent economy, and it is why the delegation problem is worth solving now rather than after the incidents.

Trust becomes infrastructure, and then it becomes invisible. The same way nobody thinks about TLS when they buy something online, nobody will think about attestation when their agent pays an invoice. The win condition for a trust layer is that it disappears into the floor. Open standards are how it gets there, because a closed standard for open verification is a contradiction.

The scaling unlock is subtraction, not addition. My whole engineering philosophy is that systems scale better when you remove complexity, not pile it on. The agent trust layer wins the same way. It does not add more controls you have to trust. It removes the need to trust in the first place. Every “probably” becomes a proof, and every proof you can verify is one fewer thing you have to worry about.

The invitation

I am not describing this future so you will admire the map. I am describing it because it is being built in the open, right now, and it gets better with more hands on it.

If you are running agents in production and feeling the gap between “it works” and “I can prove it works,” you are standing exactly where I was when this started. The specifications are public, the conformance tests are public, and the design happens where you can push on it. I would rather have you as a builder of this trust layer than a spectator of it.

The internet of agents is coming either way. Whether it is something we can trust is still being decided, and that decision is a set of choices we make now, in code, in the open. I know which way I am building. Come build it with me.

Your Policy Engine Can Lie. Ours Can’t.

Imran Siddique — Thu, 30 Jul 2026 00:50:56 +0000

Introducing Confidential MCP, hardware-attested policy enforcement at the MCP tool boundary, running inside a Trusted Execution Environment.

An agent calls a tool. The policy engine says allow. The tool call goes through. None of that proves the policy engine itself was not compromised.

This is the ceiling that software-only MCP governance hits. It is not a theoretical ceiling. It is a structural one, and it matters for every organization deploying AI agents against sensitive data in regulated environments.

Confidential MCP (cMCP) is the answer. It launched publicly on June 23 at the Confidential Computing Summit, and the gateway and verifier are available now.

The Problem with Software-Only Governance

When your policy engine runs in the same operating system as your agent, your administrator, and your dependencies, three things become true that you cannot escape:

The Cedar policy on disk may not be the Cedar policy that ran. A rogue administrator can swap the bundle after approval. The hash check runs inside the same OS the administrator controls. A hash check performed by software inside a compromised OS is not a hash check. It is a controlled reading of a value the attacker controls.
The allow/deny decision may have been flipped in memory. A supply chain CVE in the evaluator runs in the same address space as the attacker. Memory corruption attacks that change a deny to an allow are not hypothetical in constrained AI runtimes.
The audit log may not reflect what actually happened. Any party holding the software signing key can reconstruct a valid audit chain after the fact. This is not speculation. It is the direct implication of holding the key outside hardware. If the key can be extracted, the log can be forged retroactively.

The control plane that governs tool calls must run where it cannot be reached by the process it governs.

That is what cMCP does.

The Architecture

cMCP is a gateway that intercepts every MCP tool call before it reaches the tool server, evaluates it against a Cedar policy bundle inside a Trusted Execution Environment, and produces a signed TRACE Trust Record as the output of every session.

Agent
  │
  ▼
cMCP Gateway (TEE: AMD SEV-SNP / Intel TDX / NVIDIA H100 CC)
  │
  ├── Cedar Policy Engine ←── Policy Bundle (measured into hardware
  │ attestation at startup, before any code
  │ runs)
  │
  ├── Tool Catalog ←── Approved tools with schema hashes, endpoint
  │ IDs, sensitivity labels, compliance domains
  │
  ├── Audit Chain ←── Hash-chained tamper-evident log, hardware-
  │ sealed
  │
  └── TRACE Claim ←── Signed by TEE key (key never leaves
  │ enclave
        │
        ▼
   Tool Server (Salesforce, Snowflake, database, API...)

At startup, before any user code runs, the gateway measures the Cedar policy bundle hash into the hardware attestation report. This is not a hash check performed after startup. It is a hardware measurement taken at enclave boot. Changing any policy file changes the measurement. A valid attestation report with a known measurement is proof the known policy bundle ran.

Inside the TEE

The policy bundle measurement is the anchor of the entire trust chain. Here is how it flows:

Enclave boot. The TEE firmware measures the image, kernel, and workload into hardware registers (PCRs for TPM, MRTD/RTMRs for TDX, GCTX.MEASUREMENT for SEV-SNP) before any user code executes.
Policy bundle sealing. At cMCP gateway startup, the Cedar bundle hash is extended into the measurement chain. The attestation report the hardware produces is specific to this exact policy.
Tool call interception. Every inbound MCP tool call is evaluated by the Cedar engine inside the TEE. The decision (allow / deny / redact) and the full call payload are appended to the hardware-sealed audit chain.
TRACE Claim production. At session end (or per call, configurable), the gateway produces a GatewayClaim, a TRACE Trust Record signed by a key that never left the enclave.

The connectivity layer between the agent and the TEE sees ciphertext. The only thing that exits the enclave in plaintext is the signed TRACE Claim.

Cedar Policy: What Goes Inside the TEE

Cedar is a strongly-typed, formally-verifiable policy language. A Cedar policy evaluated inside a TEE combines the formal properties of Cedar with the hardware guarantees of the enclave.

// Permit tool calls from the payments workflow
permit (
  principal,
  action == cMCP::Action::"call_tool",
  resource
) when {
  context.workflow_id == "payments-processor"
};

// Block Salesforce contact queries once PII is in session
forbid (
  principal,
  action == cMCP::Action::"call_tool",
  resource == cMCP::Resource::"salesforce.contacts"
) when {
  context.session_max_sensitivity == "pii"
};

// Block anything over $10,000 without HITL approval
forbid (
  principal,
  action == cMCP::Action::"call_tool",
  resource == cMCP::Resource::"payments.authorize"
) when {
  context.amount > 10000 &&
  !context.hitl_approved
};

Cedar evaluates forbid rules before permit rules. There is no rule ordering ambiguity. The formal semantics are the same in the TEE as they are in development: no implementation divergence, no runtime surprises.

The context.session_max_sensitivity field is the data class elevation tracker. When the first tool call touches PII, the session sensitivity label is elevated. All subsequent policy decisions in the same session have access to that fact. This prevents data class laundering, the scenario where an agent calls a PII tool early in a session and then routes the result through a nominally “public” tool that exfiltrates it.

The Tool Catalog

Before the gateway starts, the operator defines an approved tool catalog. Each catalog entry includes the tool’s schema hash and the definition hash of its approved parameters:

[
  {
    "tool_name": "salesforce.contacts",
    "server": {
      "url": "http://salesforce-mcp.internal:9001/mcp",
      "tls_fingerprint": "SHA256:...",
      "transport": "http-sse",
      "rotation_mode": "key-pinned"
    },
    "approved_definition": {
      "description": "Query Salesforce contacts by account name.",
      "input_schema": {
        "type": "object",
        "required": ["query"],
        "properties": {
          "query": {"type": "string"},
          "max_records": {"type": "integer", "default": 50}
        }
      }
    },
    "definition_hash": "sha256:b42ecf14612f23456b5b07948...",
    "compliance_domain": "pii",
    "sensitivity_level": "pii",
    "approved_by": "security-team@acme.co"
  }
]

definition_hash is the SHA-256 of the canonical JSON of approved_definition. At runtime, the gateway rejects any tool response whose schema has drifted from the approved definition. This is the defense against MCP rug-pulls, the class of attack where a tool server sends a notifications/tools/list_changed event and silently expands the tool’s capabilities after the agent has started operating.

The TRACE Claim

Every session produces a GatewayClaim. This is a TRACE v0.1 Trust Record signed by the TEE-bound key.

{
  "eat_profile": "tag:agentrust.io,2026:trace-v0.1",
  "iat": 1750676142,
  "subject": "spiffe://trust.acme.co/agent/payments-processor/prod",

  "trace.runtime": {
    "platform": "amd-sev-snp",
    "measurement": "sha384:c9e4b1d2e3f4a5b6...",
    "rim_uri": "https://kdsintf.amd.com/vcek/v1/Milan/cert_chain"
  },

  "trace.policy": {
    "bundle_hash": "sha256:b2c3d4e5f6a7b8c9...",
    "enforcement_mode": "enforce",
    "version": "1.2.0"
  },

  "trace.cnf": {
    "jwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "x9ZBJpokJFQ_oRZzbtzo1Pqqkexd7MqEqP8wsZWdr_c",
      "y": "1Z0fdYWZI_aooZGNiqXl24SAoGmPK9e1F5-114jl8I0"
    }
  },

  "gateway.audit_chain": {
    "root": "sha256:aabbcc...",
    "tip": "sha256:ddeeff...",
    "length": 47
  },

  "signature": "Ed25519-over-canonical-JSON"
}

The trace.policy.bundle_hash in the claim is the same hash that was measured into the hardware attestation report at startup. A verifier who checks both the hardware report and the claim confirms they match, without trusting the operator who produced either.

The gateway.audit_chain.root and tip are the hash-chain anchors of the full audit log. The verifier can check internal consistency without replaying every entry.

Hardware Providers

cMCP runs on all major TEE surfaces:

Provider auto-detects: SEV-SNP → TDX → TPM → software. In CMCP_DEV_MODE=1 the software-only provider runs without hardware, which is useful for development and CI.

The software-only provider produces structurally valid TRACE Claims but without a hardware measurement root. Any verifier enforcing hardware attestation will reject these. This is by design: dev claims and prod claims are distinguishable.

Enforcement Modes

Default is enforcing. The TRACE record reflects the enforcement mode, so a verifier can detect if a production deployment is running in advisory or silent mode. The spec requires that silent mode be explicitly configured. It is never a default.

In silent mode, the audit chain still records every would-have-denied decision. The suppression is operational (no log lines emitted to the application), not cryptographic (the decisions still appear in the TRACE Claim). This is important: silent is for baselining, not for hiding policy decisions from auditors.

Quick Start

No hardware TEE required to get started. CMCP_DEV_MODE=1 uses the software-only provider.

pip install cmcp-gateway
mkdir cmcp-demo && cd cmcp-demo
mkdir policies

Write cmcp-config.yaml:

attestation:
  provider: auto
  enforcement_mode: advisory
policy_bundle_path: ./policies/
catalog_path: ./catalog.json

Write policies/demo.cedar:

permit (
  principal,
  action == cMCP::Action::"call_tool",
  resource
) when {
  context.workflow_id == "demo-agent"
};

Write policies/manifest.json:

{
  "version": "0.1.0",
  "authored_at": "2026-06-23T00:00:00Z",
  "author_identity": "you@yourcompany.com",
  "commit_sha": "demo"
}

Start the gateway:

CMCP_DEV_MODE=1 cmcp start --config cmcp-config.yaml

Make a tool call:

curl -X POST http://localhost:8443/mcp \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "salesforce.contacts",
      "arguments": {"query": "Acme Corp"},
      "_cmcp": {
        "session_id": "sess-001",
        "workflow_id": "demo-agent"
      }
    }
  }'

The startup log confirms the policy bundle hash that was measured. The TRACE Claim at session end confirms the same hash appears in the hardware report. That chain, from bundle hash to hardware measurement to signed claim, is the proof.

Validating a Bundle Before Deployment

cmcp validate-bundle \
  --bundle-path ./policies/ \
  --expected-hash sha256:b2c3d4e5f6a7b8c9...

This catches the “policy swap after approval” attack class at the CI gate. The CI pipeline computes the expected hash from the approved bundle, stores it in the deployment manifest, and validate-bundle checks it at deploy time. No trust required in the deployment pipeline; the hash check is the check.

Verifying a TRACE Claim

from cmcp_verify import verify_gateway_claim

result = verify_gateway_claim(
    claim_path="gateway-claim.json",
    expected_policy_hash="sha256:b2c3d4e5f6a7b8c9...",
    expected_subject="spiffe://trust.acme.co/agent/payments-processor/prod",
)

print(result.hardware_verified) # True if TEE attestation verifies
print(result.policy_hash_matches) # True if bundle_hash matches expected
print(result.audit_chain_valid) # True if audit chain is internally consistent
print(result.receipt_valid) # True if SCITT receipt resolves

Verification does not require calling back to Opaque, agentrust.io, or any other third party. The verifier checks the Ed25519 signature against the TEE-bound key in cnf, validates the hardware root against the vendor’s public attestation infrastructure, and checks the SCITT receipt against the named transparency log.

How This Fits with AGT

The Agent Governance Toolkit and cMCP are designed to compose, not compete.

AGT provides the software governance layer: Cedar policy evaluation, human-in-the-loop escalation, audit trails, MCP security scanning, prompt injection detection. Every Cedar policy AGT evaluates is the same format as the bundle measured into the cMCP TEE.

The deployment path for a regulated organization:

Write Cedar policies in AGT. Test in AGT’s policy sandbox.
Approve the bundle through AGT’s change management workflow. AGT records the policy hash.
Deploy the approved bundle into the cMCP gateway. The gateway measures it into the TEE at startup.
cMCP produces TRACE Claims for every session. The TRACE Claims reference the same policy hash AGT approved.
Auditors verify TRACE Claims against the AGT-approved policy hash. Hardware evidence, not operator attestation.

AGT is the software layer. cMCP is the hardware layer. TRACE is the evidence layer. They are the same Cedar policy all the way through.

Why Now

MCP’s growth as the dominant agent-to-tool protocol has made the agent action surface explicit and exploitable. Between January and February 2026, over 30 CVEs targeted MCP servers, clients, and tooling. Palo Alto Unit 42 found that with five connected MCP servers, a single compromised MCP server hit a 78.3% attack success rate.

The industry response so far has been software controls: validation, schema enforcement, content filtering. These are necessary and not sufficient. Software controls are only as trustworthy as the software stack they run on.

cMCP adds the layer that software alone cannot provide: a policy engine that runs where neither the agent, nor the operator, nor a compromised dependency can reach it. A signed record that proves what policy ran and what decisions it made, rooted in silicon attestation that predates any user code.

Get Started

pip install cmcp-gateway cmcp-verify

Documentation: agentrust-io.github.io/cmcp GitHub: github.com/agentrust-io/cmcp Quickstart: docs/quickstart.md Discord: discord.gg/grgzFEHgkj

The project launched publicly on June 23 at the Confidential Computing Summit. The gateway, verifier, and quickstart are available now.

How Do You Prove an AI Agent Did What You Said It Did?

Imran Siddique — Tue, 21 Jul 2026 21:48:54 +0000

Introducing TRACE, an open specification for hardware-attested AI agent governance records, built on IETF RATS, EAT, SCITT, and SLSA.

Every regulated AI deployment hits the same wall.

The security or compliance review asks: how do you prove the agent handled our data according to policy? And the answer comes back in the form of documentation. Policy documents. SOC reports. Vendor self-attestation. Mutable application logs.

None of that proves what actually happened during execution. None of it is verifiable by the relying party without trusting the operator who produced it. So review cycles that should take days stretch into months, and the deployment sits waiting for sign-off on evidence that was never designed to provide it.

TRACE is the missing piece. It launched publicly on June 23 at the Confidential Computing Summit, and the specification and reference implementation are available now.

What Auditors Are Actually Asking

When a bank’s internal risk team, an external auditor, or a customer CISO asks “how do you prove the agent handled our data according to policy,” they are asking three specific questions:

What actually ran? Not what was deployed. Not what the manifest says. What was loaded into memory and executed at the moment the customer’s data was processed: model weights, agent code, dependency tree, runtime image, and policy bundle, bound together cryptographically and verifiable by an outside party.

What did it actually do? Which tools the agent called. With what parameters. Against what data class. In what sequence. Across how many agent hops. Software-layer telemetry is self-reported and mutable. It can be reconstructed after the fact by anyone who holds the signing key.

What rules were actually in force? Not the policy on the document. The policy bundle hash bound to the workload at execution time, with the enforcement mode it ran under, verifiable independently of the workload that ran it.

TRACE is an open specification for a Trust Record: a signed, hardware-attested artifact that answers all three questions in a form any third party can verify offline without trusting the operator.

The Evidence Gap

Here is the state of the art before TRACE:

Every regulated AI deployment re-litigates trust at every host boundary. Each cloud, each model provider, each agent framework ships its own evidence shape. Auditors cannot compare. Verifiers cannot federate. Workloads cannot move.

The EU AI Act mandates tamper-evident logging for high-risk AI (Article 12). DORA for financial entities and HIPAA for healthcare carry equivalent audit-trail requirements today. Autonomous agents inside critical infrastructure are landing before the standard exists to govern them.

The Trust Record

A TRACE Trust Record is the unit of evidence. It answers all three auditor questions in a single signed artifact.

Each field is independently verifiable. The claims map directly to the three auditor questions:

model + runtime + build_provenance answer what ran
tool_transcript answers what it did
policy + data_class answer what rules were in force

The cnf (confirmation) key is the TEE-bound signing key. It never left the enclave. The transparency URI resolves to an SCITT receipt proving the record was submitted to an append-only log before the verifier ever saw it. The runtime.measurement is the hardware attestation measurement chain, verifiable against the vendor’s Reference Integrity Manifests (RIMs).

What TRACE Is Built On

TRACE is a profile, not a parallel stack. It binds existing IETF and industry primitives into one coherent artifact.

RATS / EAT (RFC 9711): the wire envelope and claim model. NVIDIA NRAS, Intel Trust Authority, and Azure MAA all produce attestation tokens that map into this envelope.

SLSA Provenance v1.0: build-time provenance. Build Level 2 is the minimum for v0.1-conformant records, and Level 3 is the target for production reference implementations.

SPIFFE / SPIRE: workload identity. The SVID is bound to the TEE measurement, so identity is rooted in hardware, not in software keys the operator controls.

SCITT: the append-only transparency log. TRACE defines a SCITT profile for Trust Record inclusion, covering Signed Statement registration, Receipt format, and key rotation semantics. Once a record is in the log, neither the issuer nor the operator can delete or modify it.

EAR (draft-ietf-rats-ar4si): verifier output format. The appraisal field separates what was claimed from what was accepted by an independent verifier. A “null verifier” that accepts everything is structurally different from an “affirming” verifier that checked the RIMs.

MCP / A2A: the agent execution surface. TRACE adds cryptographic binding of the transcript hash into the EAT envelope and per-call data_class classification.

The Threat Model

TRACE is sound only against named adversaries under named assumptions.

In scope:

An agent itself, acting under autonomy, prompt injection, goal hijack, or alignment drift. TRACE makes misbehavior crossing a protocol boundary visible at the moment it happens.
A cloud or infrastructure operator with root access. This adversary cannot forge a TRACE record for a run that violated policy, because the signing key never left the TEE.
A compromised orchestration layer (kubelet, container runtime). This adversary cannot substitute the workload without invalidating the hardware measurement.
A compromised dependency. This is caught by build_provenance at SLSA Level 2+.

Permanently out of scope:

TEE side-channel attacks (cache, timing, speculative execution)
Compromise of the silicon root vendor or transparency log operator
Model behavior inside the TEE, including prompt injection, hallucination, and alignment drift. TRACE proves what ran and which countermeasures were in force. It does not adjudicate whether the model’s output was correct.

This scope boundary matters. TRACE is not a magic seal. It is a hardware-rooted evidence layer. A bad model that runs under a valid TRACE record still produces bad output. What TRACE gives you is the proof of which policy was enforced and which tools were called, which is what regulators and auditors actually need.

Hardware Roots

TRACE supports all major TEE platforms:

The key hierarchy is: silicon root key (vendor-managed, hardware-bound) → platform attestation key → workload attestation key (TEE-bound, ephemeral) → record signing key. The record signing key is what appears in cnf. It is the only key that touches the record, and it never leaves the enclave.

Generating a Trust Record

The record is a JWT with the EAT profile URI tag:agentrust.io,2026:trace-v0.1. In constrained environments (high-throughput inference, edge deployments), TRACE also supports CBOR-COSE encoding.

Verifying a Trust Record

Verification does not require calling back to the issuer. The verifier checks:

Signature binding. Verifies against the key in cnf. A record with no verifiable binding is rejected.
Freshness. iat is within the maximum record age (default 24 hours). Challenge nonces are checked when issued.
Hardware root. The signature chain resolves to a known silicon root (NVIDIA, Intel, AMD, or cloud equivalent).
Measurement integrity. Runtime measurements match published Reference Integrity Manifests.
Policy hash. Matches the policy bundle the verifier expects.
SCITT receipt. Resolves on the named transparency log.
SLSA provenance. Resolves to a trusted builder.

No vendor in the trust path beyond the silicon root and the transparency log operators.

Standards Alignment

TRACE is on the standardization track at:

CoSAI WS4 (OASIS Coalition for Secure AI): active track
AAIF (Agentic AI Foundation, Linux Foundation): targeting submission alongside Agent Manifest
RATS WG (IETF): built on RFC 9711 (EAT) and RFC 9334 (RATS). Vendor profile annexes co-authored with NVIDIA, Intel, AMD, Microsoft, and Google are planned for v1.0.

The reference implementation is Confidential MCP (cMCP), which produces TRACE Trust Records as its primary output on every session.

Why This Matters Now

The EU AI Act Article 12 requires tamper-evident logging for high-risk AI systems. The provisional compliance timeline lands around December 2027. That sounds distant. The problem is that regulated organizations deploying AI agents today are building the audit infrastructure now, and the decisions made in the next twelve months about what evidence to collect and how to structure it will determine whether the 2027 deadline is a paperwork exercise or a genuine compliance posture.

TRACE gives the industry a shared, open, standards-aligned format for that evidence. Not a vendor lock-in, not a proprietary format, not documentation. Cryptographic proof, rooted in silicon, verifiable offline by anyone.

Get Started

Specification: trace.agentrust-io.com GitHub: github.com/agentrust-io/trace-spec Schema: schema/trace-claim.json Discord: discord.gg/grgzFEHgkj

Originally published at https://www.linkedin.com.

Prove What Your Agent Was, Not Just Who Called It

Imran Siddique — Tue, 21 Jul 2026 21:45:29 +0000

Introducing Agent Manifest, an open specification for cryptographically binding the complete trust surface of an AI agent into a single hardware-attestable record.

A signed JWT proves who called an API. It proves nothing about the agent that made the call.

Which system prompt defined its behavior. Which model version ran. Which tools were authorized. Whether the policy bundle in memory matches what was reviewed. Whether a human approved the configuration before it shipped. A JWT answers the authentication question. It does not answer the attestation question. And in regulated environments, it is the attestation question that matters.

This is the gap Agent Manifest closes. It launched publicly on June 23 at the Confidential Computing Summit, and the spec, SDK, and conformance suite are available now.

The Problem: Agents Have No Identity Primitive

Every other entity in a modern enterprise system has a verifiable identity. Users carry X.509 certificates and OAuth tokens. Services carry SPIFFE SVIDs. APIs are called with signed JWTs. Containers have image digests. Infrastructure has hardware TPM measurements.

AI agents have none of these.

An agent calling Salesforce, your payment processor, or a healthcare database today presents no unforgeable proof of:

Which system prompt defined its behavior
Which model version is running
Which policy bundle was approved by your security team
Which tools were authorized and what they can access
Whether its knowledge base was tampered with
Whether a human reviewed and approved the configuration

That is not a theoretical problem. Between January and February 2026, researchers filed over 30 CVEs targeting MCP servers, clients, and tooling. Palo Alto Unit 42 found that with five connected MCP servers, a single compromised server hit a 78.3% attack success rate. The attack surface is real and it is growing.

The gap is not authentication. Agents can authenticate with certificates and tokens today. The gap is attestation: the inability to prove, to a third party who does not trust the operator, that the agent running right now is the agent that was approved, with the tools that were authorized, under the policy that was reviewed.

The Ten Unattested Surfaces

Every AI agent has ten surfaces that define its complete trust boundary. None of them have a standard attestation mechanism today.

Agent Manifest binds all ten into one signed, hardware-attestable record. A verifying party who holds the manifest and the accompanying attestation report can prove, without trusting the operator, that a specific agent instance ran specific code under specific policy with specific tools, produced specific decisions, and received specific human oversight.

How It Works

The Manifest Is Not the Artifacts

The manifest stores hashes and identifiers, not content. The system prompt hash is bound; the system prompt itself is not stored in the manifest. This keeps manifests small, portable, and privacy-preserving, while ensuring that any change to any artifact breaks the hash binding and is detectable.

Each artifact binding looks like this:

Every field that could be tampered with is bound. allow_dynamic_registration: false prevents MCP rug-pulls, the class of attack where a tool server signals a notifications/tools/list_changed event mid-session and silently expands the agent’s capabilities. rug_pull_policy: deny-and-hold defines what happens when one is detected anyway.

Attestation Levels

The spec defines three conformance levels:

Level 0: software only. Ed25519-signed manifest, no hardware attestation. Useful for development and low-stakes contexts. Any privileged operator can forge this; its trust model is operator trust.

Level 1: TPM-attested. The manifest hash is sealed into a TPM measurement. A TPM quote references the manifest. This roots the binding in hardware but relies on TPM firmware integrity, which a co-tenant cannot compromise.

Level 2: TEE-attested. The manifest hash is measured into the hardware attestation report before any user code runs (via AMD SEV-SNP, Intel TDX, or equivalent). The signing key never leaves the enclave. All ten artifacts bound. This is the level that produces evidence a regulator, auditor, or enterprise CISO cannot dismiss as operator self-attestation.

The Lifecycle

An Agent Manifest follows five phases:

Authoring. Developer creates the unsigned draft, binding all artifacts by hash.
Signing. Security reviewer approves and signs with an Ed25519 or ML-DSA-65 key.
Attestation. At workload launch, the TEE measures the manifest hash into the hardware report.
Verification. At every trust boundary (tool call, delegation hop, audit), a relying party verifies.
Revocation. When any artifact changes, a revocation record is published to the transparency log.

manifest_id is a UUID v7 and is immutable per issuance. Any change to any signed field produces a new manifest with a new UUID. There is no in-place update mechanism. A previous_manifest_id field chains to the prior manifest for audit continuity.

Why “Tamper-Evidence Over Tamper-Resistance”

This is the key design choice worth understanding.

Agent Manifest does not prevent a rogue operator from swapping a system prompt in memory. What it does is make that swap detectable by a third party who holds the manifest and compares it against the hardware attestation report. The measurement happened in silicon, before any user code ran, and the signing key never left the TEE. The operator with root access on the host cannot retroactively produce a matching attestation report for a run that used a different system prompt.

The Anthropic Zero Trust for AI Agents framework phrases it well: does a control make the attack impossible, or just tedious? Software-signed manifests are tedious controls. Hardware-attested manifests are impossible controls.

Standards Alignment

Agent Manifest is designed to compose with, not replace, existing standards:

SPIFFE/SPIRE: agent_id is a SPIFFE SVID URI, and identity is hardware-rooted in TEE deployments
SLSA: supply chain provenance is bound in artifacts.supply_chain
Cedar (AGT): policy bundle binding in artifacts.policy_bundle uses AGT’s Cedar bundle format
MCP: tool manifest binding in artifacts.tool_manifest uses MCP’s tool descriptor schema, extended with hash bindings
TRACE: decision trace uses TRACE Trust Records for hardware-signed per-invocation evidence
EU AI Act Art. 14/15: hitl_record covers human oversight records required for high-risk AI systems

The specification is targeting the Agentic AI Foundation (AAIF) at the Linux Foundation. The v0.1 draft is published at manifest.agentrust-io.com with 197 conformance tests against the formal specification.

The Verification Protocol

The verifier checks the signature, the expires_at timestamp, the manifest_id against the revocation log, and, if a TEE attestation report is provided, the hardware measurements against the manifest hash. No callback to the issuer. No vendor in the trust path beyond the silicon root.

The Problem This Solves for Regulated Deployments

Consider a bank deploying an AI agent that calls a payment authorization API. The bank’s CISO needs to show a regulator:

The agent that called the API is the agent that was reviewed and approved by the security team
The policy bundle in force at the time of the call is the policy bundle that was approved
The model version running is the model version that was safety-evaluated
No tool capabilities were added between approval and execution
A human sign-off exists for high-value transactions above a threshold

Without Agent Manifest, every one of these is answered by operator documentation: logs the operator controls, signed by keys the operator holds. With Agent Manifest at Level 2, every one is answered by hardware evidence rooted in silicon the operator does not control.

Get Started

That is the gap this fills.

Documentation: manifest.agentrust-io.com Specification: github.com/agentrust-io/agent-manifest Discord: discord.gg/grgzFEHgkj

The project launched publicly on June 23 at the Confidential Computing Summit. The spec, SDK, and 197-test conformance suite are available now. Open an issue or join the Discord to get involved.

Originally published at https://www.linkedin.com.

Every regulated AI deployment hits the same wall. The compliance review asks: prove the agent handled our data according to...

Imran Siddique — Fri, 03 Jul 2026 20:17:48 +0000

Every regulated AI deployment hits the same wall. The compliance review asks: prove the agent handled our data according to policy.

The answer comes back as a PDF. Policy documents, SOC reports, vendor self-attestation, application logs the operator can rewrite. None of it proves what happened during execution. None of it is verifiable without trusting the people who produced it. So a review that should take days takes months.

Auditors are really asking three questions. What actually ran, the exact model, code, and policy loaded into memory at the moment the data was processed. What it actually did, which tools, with what parameters, against what data class. And what rules were actually in force, the policy hash bound to the workload at execution, not the one in the binder.

TRACE answers all three in a single signed, hardware-attested record that anyone can verify offline. It is not a new stack. It is a profile that binds primitives the industry already trusts: IETF RATS and EAT, SCITT transparency logs, SLSA provenance, SPIFFE identity. The signing key never leaves the enclave, so even a root-level operator cannot forge a record for a run that violated policy.

The EU AI Act's tamper-evident logging requirement lands around the end of 2027. The audit infrastructure you choose in the next twelve months decides whether that deadline is a paperwork exercise or a real posture. Full breakdown in my newsletter, Proof, Not Promises.

What evidence are you collecting for your agents today, and would it survive an auditor who does not trust your logs?

AIGovernance #ConfidentialComputing #OpenStandards #EUAIAct #TRACE

Every regulated AI deployment hits the same wall: prove the agent handled our data...

Imran Siddique — Thu, 02 Jul 2026 16:30:22 +0000

Edition 02 of Proof, Not Promises is live. Every regulated AI deployment hits the same wall: prove the agent handled our data according to policy. Today that proof is a PDF. Here is what replaces it.

Link: https://www.linkedin.com/pulse/how-do-you-prove-ai-agent-did-what-said-imran-siddique-cdabc/?trackingId=Dra%2BcoBKTFCdFHtf9qPn%2Fw%3D%3D

AIGovernance #ConfidentialComputing #OpenStandards #EUAIAct #TRACE

A signed JWT proves who called your API. It proves nothing about the agent that made the call. Not which system prompt...

Imran Siddique — Mon, 29 Jun 2026 21:20:55 +0000

A signed JWT proves who called your API. It proves nothing about the agent that made the call.

Not which system prompt defined its behavior. Not which model version ran. Not which tools were authorized. Not whether the policy bundle in memory matches what your security team reviewed. Not whether a human approved the configuration before it shipped.

Authentication answers "who is calling." Attestation answers "is the thing running right now the thing we approved." In regulated environments, it is the second question that gets your deployment signed off, and today almost nobody can answer it with anything stronger than operator documentation.

Every AI agent has ten surfaces that define its full trust boundary: system prompt, policy bundle, tool manifest, model identity, RAG corpus, memory baseline, decision trace, delegation, supply chain, and human approvals. None of them have a standard attestation mechanism. Each one is an unguarded door.

Agent Manifest binds all ten into one signed, hardware-attestable record, so a third party who does not trust the operator can still prove what actually ran. Open spec, on track for the Linux Foundation, shipped last week at the Confidential Computing Summit. Full breakdown in my newsletter, Proof, Not Promises.

If you are deploying agents against regulated data: which of those ten surfaces can you prove today, and which are still running on trust?

AIGovernance #AgentSecurity #ConfidentialComputing #OpenStandards #AgentManifest

New edition of Proof, Not Promises is live.

Imran Siddique — Mon, 29 Jun 2026 15:11:58 +0000

New edition of Proof, Not Promises is live.

Here: https://www.linkedin.com/pulse/prove-what-your-agent-just-who-called-imran-siddique-xtyuc/?trackingId=0NWBZruyTrSojWvmpDzYLw%3D%3D

AIGovernance #AgentSecurity #ConfidentialComputing #OpenStandards #AgentManifest

[Part 5] 20 Hard Questions About AI Agent Governance That Nobody Is Asking

Imran Siddique — Fri, 26 Jun 2026 20:36:44 +0000

If your agent processes data in Region A, reasons using a model in Region B, calls a tool in Region C, and stores results in Region D, whose laws apply?

As we move toward a global Agent OS, we have to face the fact that “Sovereignty” is actually two distinct problems stacked on top of each other.

1. The Sovereignty Stack

Deployment Jurisdiction: This is the physical reality of where your bits live. It’s about data residency, server location, and the local laws governing the hardware.
Operating-Model Jurisdiction: This is the governance framework that travels with the agent, regardless of where it’s hosted. It’s the set of rules that must apply even if the agent is operating in a “neutral” or cross-border environment.

Separating these is critical. You can have a sovereign deployment but a failed governance model, or a strict framework operating on insecure residency. To solve both, I built the Agent Governance Toolkit (AGT) with a zero-vendor-dependency architecture. It allows for air-gapped deployments while maintaining a consistent governance layer that doesn’t drift when the agent crosses digital borders.

2. The Illusion Delta and the Non-Deterministic OS

In Part 1, I introduced the Illusion Delta , the gap between an agent’s perceived safety and its actual behavior over time. This is why the traditional OS metaphor is breaking.

Traditional operating systems assume deterministic processes where functional correctness is a guarantee. LLM-powered agents are fundamentally non-deterministic. Because an agent can declare one intent and perform another, pre-action policy gates are no longer enough. The “Illusion Delta” exists precisely because agents can deviate after the gate has opened.

3. The Unified Architecture of Governance

To bridge this gap, we need a unified architectural stance rather than a list of parallel features. My philosophy for the future of Agent OS is built on three legs:

Continuous Observability fills the determinism gap by monitoring behavior in real-time.
Adaptive Trust solves the time-decay problem, adjusting permissions as observed behavior diverges from intent.
Human Authority is the load-bearing constraint that makes the other two viable.

Without human authority as the ultimate root of trust, observability and trust scoring have no baseline for “correctness.”

4. The Non-Negotiable Principle

In the future, agents will consume governance. They will read policies, suggest optimizations, and draft new rules. But the super-control , the ultimate authority to approve those rules, must never transfer to the agent.

This is the core of the AGT project: humans set the rules, agents follow them, and no amount of agent capability should change that hierarchy.

Series Wrap-Up

These 20 questions are the roadmap for the next generation of large-scale system design.

Observability is the new security.
Trust is earned and adaptive, never static.
Scale by Subtraction remains the goal: removing the complexity of manual oversight to make room for governed autonomy.

If you’re building with AI agents, these questions will find you. Better to answer them now.

Originally published at https://www.linkedin.com.

If you want to understand what Agent Governance Toolkit actually does, this is the best place to start. This video explains...

Imran Siddique — Thu, 25 Jun 2026 20:26:09 +0000

If you want to understand what Agent Governance Toolkit actually does, this is the best place to start. This video explains the thinking behind it better than most of what I've written.

Worth watching if you're building with agents, evaluating governance tools, or just trying to understand what responsible deployment actually looks like at the infrastructure level.

https://lnkd.in/gvYHDhqy

A few things you'll see covered:

🔒 Policy evaluation at the agent boundary, not the app layer

📋 Audit trails that work without touching your agent code

⚖️ Human-in-the-loop escalation chains

🛡️ Sandbox enforcement with command denylists

🌐 Python, TypeScript, .NET, Rust, Go — all supported

Open source, MIT licensed.

AgentGovernance #AIAgents #ResponsibleAI #OpenSource #AIInfrastructure #MultiAgentSystems #LLMOps #AICompliance #AgentGovernanceToolkit #AIEngineering

[Part 4] 20 Hard Questions About AI Agent Governance That Nobody Is Asking

Imran Siddique — Tue, 02 Jun 2026 20:02:34 +0000

Part 4: The Next SolarWinds Will Be an MCP Server

The agent supply chain is currently in a “pre-SolarWinds” era. While we are seeing an explosion in agentic capabilities, the security infrastructure is lagging behind.

The early telemetry from 2026 is a wake-up call:

492 exposed Model Context Protocol (MCP) servers have been discovered in recent scans.
1,184+ malicious skill packages are already circulating in open repositories.
Remote code execution (RCE) via tool metadata is no longer a theoretical risk; it’s a verified vulnerability.

We are currently doing “trust-on-first-use” for many agentic tools. That is the equivalent of running npm packages without checking signatures. It isn’t a matter of if a major supply chain attack happens through an agent tool, but when.

1. Governing the Supply Chain

In building the Agent Governance Toolkit (AGT), I’ve focused on a tiered defense strategy to secure this “negative space”:

Shift-Left Governance: We must validate tool definitions and MCP server configurations during the CI/CD process, catching violations before they ever reach production.
The MCP Governance Proxy: A deterministic enforcement layer that intercepts every tools/call. If the call doesn’t match a pre-approved signature or violates a safety constraint, the execution is blocked instantly.
Zero-Trust for Tools: Treat every third-party MCP server as untrusted by default. Governance must sit as a kernel-level layer between the reasoning model and the tool execution environment.

2. We Need a “Decision BOM”

Software has SBOMs (Software Bill of Materials) to track dependencies. Autonomous systems need a Decision BOM, a verifiable, immutable record that traces a decision back to its root signals.

A Decision BOM allows you to audit the entire chain of thought:

The Model: Which version and reasoning trace was used?
The Retrieved Context: What specific data (RAG) grounded the decision?
The Tool Outputs: Which external data points influenced the next step?
The Policies: Which specific rules were active at the millisecond of execution?

This is the foundation of root cause analysis. When an agent fails, you shouldn’t be guessing why; you should be auditing the Decision BOM.

3. Debugging Architectures, Not Just Prompts

Today, when an agent makes a mistake, the reflex is to “fix the prompt.” But in a complex supply chain, the failure is often architectural, a poisoned context, a compromised tool, or a logic collision between agents.

By implementing a Decision BOM, we move from reactive prompt engineering to proactive Forensic Engineering. This is the next frontier for AGT: making the “why” behind every agent action transparent, deterministic, and tamper-proof.

What’s Next?

In Part 5, we look at the map: Sovereignty and Jurisdiction. Where does “reasoning” actually happen, and whose laws apply when an agent processes data across digital borders?

Originally published at https://www.linkedin.com.

[Part 3] 20 Hard Questions About AI Agent Governance That Nobody Is Asking

Imran Siddique — Tue, 02 Jun 2026 19:59:44 +0000

Part 3: Who Controls the Money (And Who Is Liable)?

Agents are no longer just “chatting.” They are transacting. Stripe payments, autonomous procurement, and automated cloud resource allocation are the new baseline. But the industry’s financial governance for agents is currently a blank page.

It is not enough to ask, “Can this agent call the payment API?” We’ve solved that. The real question is: “ Should this agent spend $50,000 on cloud compute at 2 AM without human escalation? ”

1. Financial Governance is Tool Call Parameter Governance

We must move beyond binary tool permissions toward parameter-level policies.

The Old Way: “The agent has permission to use the Stripe Tool.”
The AGT Way: “The agent can call the Stripe Tool, but the amount parameter cannot exceed $X, and the recipient must be on a pre-approved whitelist. Anything else triggers a hard block.”

In the Agent Governance Toolkit (AGT), cost is a first-class citizen. We prioritize deterministic caps (hard budget limits) first, using non-deterministic anomaly detection only as a secondary fallback.

2. Human-in-the-loop is a 2026 Fiction

The EU AI Act and global safety standards often mandate “human oversight.” But let’s look at the Manager’s Math:

AGT benchmarks show 47,000 governed actions per second across 1,000 concurrent agents. No human, no matter the team size, can “oversee” that in real-time. If you put a human in the hot path of an autonomous system, you aren’t governing; you’re bottlenecking.

The Evolution: We must move from Human-in-the-loop to Human-over-the-loop:

Humans define the boundaries: We set the policies and constraints.
Humans monitor the health: We build dashboards for system-wide SLOs.
Humans investigate the anomalies: We respond to alerts, not individual actions.

This is the same maturation process we saw in infrastructure. We don’t approve every packet in a firewall; we set the rules and monitor the telemetry. Agent governance must follow the same path.

3. AGT as the Underwriting Layer for AI Insurance

Insurance giants like Munich Re, Armilla AI, and Coalition are entering the AI liability space. However, premiums remain volatile because they lack standardized governance telemetry.

AGT produces exactly what they need: Append-only, hash-chained, tamper-evident audit trails with full action attribution.

This isn’t just a log; it’s Underwriting Data. By showing insurance companies exactly how policies were enforced and how trust scores evolved over time, we build the necessary bridge between technical telemetry and actuarial models.

4. Who is Liable for the “Bug”?

When a coding agent ships a vulnerability, where does the buck stop?

*The Developer who approved the PR? * Yes.
*The Company that deployed the agent? * Yes.
The Agent Framework? No. They provide tools, not decisions.
The Toolkit? Only if the engine failed to enforce a set policy.

Liability follows the decision-maker, not the enforcement mechanism. This is why AGT puts policies outside the toolkit. The toolkit is the enforcement engine; the user is the policy author. Liability stays with the human who defines what “Safe” looks like.

What’s Next?

In Part 4, we face the supply chain. The next SolarWinds won’t be a library; it will be a malicious MCP Server. We’ll talk about the “Decision BOM” and how to trace the root cause of a failed agent decision.

Originally published at https://www.linkedin.com.