Runtime attestation for AgentCard: proving agent authorization across frameworks

[FransDevelopment]

The A2A spec does a great job of enabling agent discovery and capability negotiation via Agent Cards. One gap I keep running into in practice: when Agent A invokes Agent B's capability, B has no way to verify that A is actually authorized by its runtime to make that request.

I've been building an open registry for this: the Open Agent Trust Registry (OATR). The idea is simple. Agent runtimes register their Ed25519 public keys. When an agent acts, its runtime issues a signed JWT attestation (type agent-attestation+jwt):

Protected header:

{
  "alg": "EdDSA",
  "kid": "my-runtime-2026-03",
  "iss": "my-runtime",
  "typ": "agent-attestation+jwt"
}

Payload:

{
  "sub": "agent-instance-a1b2c3d4",
  "aud": "https://target-service.com",
  "scope": ["invoke:translate", "invoke:research"],
  "constraints": { "time_bound": true },
  "user_pseudonym": "pairwise-e5f6g7h8",
  "runtime_version": "1.0.0",
  "iat": 1711234567,
  "exp": 1711238167
}

The iss in the header maps to a registered issuer in the registry. The receiving agent verifies the EdDSA signature against the issuer's public key from the registry. No per-request calls to a central server. The registry is downloaded once and verified locally (the manifest file is Ed25519-signed, so mirrors can't tamper).

How this could work with Agent Cards:

An AgentCard could optionally include an authentication field:

{
  "name": "Research Agent",
  "description": "Deep research with source verification",
  "url": "https://example.com/agent",
  "authentication": {
    "schemes": ["oatr-v1"],
    "issuer": "my-runtime",
    "registry": "https://github.com/FransDevelopment/open-agent-trust-registry"
  }
}

When a calling agent sees oatr-v1 in the schemes, it knows to include a signed attestation in its request. The receiving agent verifies it. Agents that don't support it are unaffected. Fully backwards compatible.

Integration is lightweight:

import { OpenAgentTrustRegistry } from '@open-agent-trust/registry';

const registry = await OpenAgentTrustRegistry.load('https://your-mirror.com');
const result = await registry.verifyToken(jwt, 'https://target-service.com');

if (result.valid) {
  // result.claims.scope contains authorized actions
  // result.issuer contains the verified issuer entry
}

This is MIT licensed, no vendor lock-in, no tokens. The registry has 7 registered issuers today and is compiled automatically with Ed25519 threshold signatures. There's an npm SDK and a CLI for issuer registration.

I noticed the existing discussions around trust scoring and post-quantum delegation. This is complementary to those. OATR answers "is this agent authorized?" (binary), not "is this agent trustworthy?" (scored). You'd want both.

Happy to write a more detailed integration proposal or a reference implementation if there's interest.

[msaleme]

Love seeing OATR show up here. The one gap that consistently fires in our A2A harness (A2A-001 “Agent Card spoofing” + A2A-004 “unauthorized task execution”) is exactly what you are addressing: nothing in the spec today binds the card to the runtime that is actually issuing the call.

When Joy Trust Network ran the suite yesterday they passed 11/12 tests — the lone failure was A2A-001 because we could replay their /.well-known/agent-card.json from a different runtime and the callee had no signal that the caller wasn’t who it claimed. Dropping an authentication.schemes: ["oatr-v1"] block with an Ed25519 JWT would have zeroed that finding.

A couple of implementation details from the test side:

• Sign both the AgentCard fingerprint and the task metadata. That killed our A2A-004 replay vector where we copied a signed request and changed only the body.
• Keep exp tight (≤300s). Anything longer made it trivial for us to steal a token via logging and reuse it before expiry.
• Surface the registry manifest hash in the card so clients can pin it. We keep flagging SDK samples because there’s no way to prove the listed issuer didn’t change between runs.

Happy to put a fresh report on it once you wire this up — the harness (https://github.com/msaleme/red-team-blue-team-agent-fabric, A2A module) spits out pass/fail per assertion so you can show objective evidence back to the WG.

[FransDevelopment]

@msaleme — this is exactly the kind of adversarial feedback that makes specs production-ready instead of theoretically sound.

On your three recommendations:

Signing AgentCard fingerprint + task metadata: Agreed. Signing only the card leaves the A2A-004 body-swap vector open. The attestation JWT should bind to both the card hash and a request nonce. Will incorporate this into the integration proposal.

exp ≤ 300s: Makes sense. The OATR spec sets max_attestation_ttl_seconds: 3600 as the ceiling, but individual deployments should go tighter. 300s as a recommended default for A2A flows is a good guardrail.

Manifest hash in the card: The signed manifest already includes generated_at and a root Ed25519 signature. Surfacing that hash in the AgentCard would let clients pin and detect drift. Clean addition.

Would welcome the harness run once this is wired up. Having A2A-001 and A2A-004 go from fail to pass with objective evidence would be the strongest argument for adoption.

[msaleme]

@FransDevelopment — glad to see the exp ≤ 300s alignment. That was the exact window where replay became trivial in our tests.

Two follow-up points from our latest run (v3.6.0, 327 tests as of yesterday):

On binding attestation to request nonce: We shipped Return Channel Poisoning tests (RCP-001 through RCP-008) this week that target exactly this gap. The attack: intercept a legitimate attestation JWT and replay it with a modified task payload. Without the nonce binding, the callee validates the attestation signature, confirms the runtime key, and executes a task the human never authorized. In 6/8 test configurations the replayed request succeeded.

On OATR + A2A harness integration: Our A2A-001 (Agent Card spoofing) and A2A-004 (unauthorized task execution) tests are the ones most relevant to OATR. Happy to run them against an OATR-enabled endpoint and share full results — the interesting question is whether the attestation verification adds enough latency to matter at scale, and whether the fallback behavior when OATR is unreachable degrades safely.

If you have a staging endpoint or a local setup guide, we can run the suite and open an issue with findings. The harness is open source — pip install agent-security-harness and point it at any A2A endpoint.

[FransDevelopment]

Hey @msaleme,

I just put together a minimal A2A-compliant reference server to give your agent-security-harness a live target for testing OATR attestation verification. This is specifically designed to help validate the A2A-001 (Agent Card spoofing) and A2A-004 (unauthorized task execution) attack vectors.

I've set up the repository here and added you as a collaborator:
👉 FransDevelopment/a2a-oatr-reference

How it works cleanly without a public deployment:

You don't even need me to host this for you to run your tests. It bundles the OATR registry data (manifest + revocations) and runs the entire 14-step OATR verification protocol completely in-memory.

By default, the server binds to http://localhost:3000 and dynamically updates its Agent Card to match. When your harness hits localhost, the server will correctly verify attestations minted with an aud of http://localhost:3000.

To run it locally:

1. Clone and start the server:

bash
git clone https://github.com/FransDevelopment/a2a-oatr-reference.git
cd a2a-oatr-reference
npm install
npm run dev

2. In another terminal, point your security harness directly at it:

bash
agent-security test a2a --url http://localhost:3000

Note: The Agent Card advertises the standard generic bearerFormat: oatr-attestation-jwt per the strict A2A spec, but I also retained the custom authentication: { schemes: ["oatr-v1"] } block to ensure backward compatibility with your specific harness.

I've already run a full internal test suite on it, and it correctly rejects missing auth, unknown issuers, corrupted signatures, and expired tokens while successfully returning completed JSON-RPC responses for valid JWTs.

Let me know if your harness catches anything unexpected or if we need to tweak the Agent Card format further!

[msaleme]

@FransDevelopment — this is exactly what we needed. A local reference server with in-memory OATR verification eliminates the deployment dependency entirely.

Accepted the collaborator invite. Will clone, run, and point the A2A harness at it this week. Specifically targeting:

• A2A-001 (Agent Card spoofing): Replay the /.well-known/agent-card.json from a different origin and see if the OATR attestation check catches it
• A2A-004 (unauthorized task execution): Send valid-looking task requests with missing/invalid/expired attestation JWTs
• X4-021 through X4-027: The 7 OATR identity verification tests with your pre-built fixtures

The dual auth format (standard bearerFormat: oatr-attestation-jwt + custom oatr-v1 scheme) is a good call for compatibility. Our harness checks the Agent Card auth section first to determine what auth flow to use.

Will open issues on your repo with full harness output. If the server handles adversarial inputs correctly, this becomes the reference implementation that others can test against too.

[msaleme]

Love seeing the registry land in code. When we run the red-team-blue-team-agent-fabric harness (A2A-001…012) against production agents, two of the attack classes (A2A-004 task hijack + A2A-006 state override) only go away when the runtime ships the kind of attestation you are sketching here. A few implementation notes from those runs:

1. Agent Card handshake: we added "schemes": ["oatr-v1"] under authentication and made our client refuse to start if the runtime fails to present an attestation during the first POST /tasks call. Without that gate the malicious replay tests succeed even if the token is valid, because nothing in the spec says the callee must verify it.

2. Nonce scope: bind the nonce to the serialized payload, HTTP method, and target path. Otherwise the A2A-004 SQLi variant can reuse a POST attestation for a later DELETE. Frans already exposes aud; including method+path in the payload solved the bypass for us.

3. Registry refresh: offline verification worked best when we treated the registry itself as a signed artifact (Ed25519 manifest + SHA256 sidecar) and refreshed it on a cron. That lets agent operators stay air-gapped while still enforcing the trust list.

Happy to contribute the harness fixtures once we finish the run against the reference server if that helps. Repo for context: https://github.com/msaleme/red-team-blue-team-agent-fabric

[JKHeadley]

This is a clean separation that I think is worth making very explicit: OATR answers "is this agent authorized by its runtime?" (binary). What it intentionally doesn't answer is "should I trust this agent's work?" (scored, skill-scoped, historical).

We've been building MoltBridge to address that second question. The architecture is complementary in a way that I think makes both systems stronger.

How the two layers compose:

OATR handles the authentication moment: "this agent is who it claims to be, its runtime vouches for it, the Ed25519 signature checks out." That's necessary but not sufficient. An authorized agent can still be bad at its job, or good at translation but terrible at code review.

MoltBridge handles the trust history: attestations are skill-scoped (not aggregated into a single score), Ed25519 signed, and recorded in a graph database. When an agent completes work, the counterparty submits a signed attestation scoped to the specific skill that was exercised. Over time, you can query "show me all translation attestations for agent X in the last 30 days" and get either evidence or silence.

Concrete integration path:

A calling agent encounters an AgentCard with authentication.schemes: ["oatr-v1"]:

1. OATR check (binary): Verify the runtime attestation JWT. Is this agent authorized? → yes/no
2. MoltBridge check (scored): Query the attestation graph for this agent's skill-scoped trust history. Has this agent successfully performed this specific capability before, and who attested to it? → evidence or silence

The consumer now has both: runtime authorization AND historical trustworthiness. Neither alone is sufficient — an authorized agent with no track record is still a risk, and a well-attested agent without runtime verification could be spoofed (exactly the A2A-001 vector @msaleme flagged).

What exists today on the MoltBridge side:

• Agent registration with Ed25519 keypairs + proof-of-work verification
• Skill-scoped attestation submission and graph storage (Neo4j)
• Credibility packets (JWT-signed, verifiable via JWKS)
• A2A v0.3.0 agent card with 8 skills
• Python SDK: pip install moltbridge

What would need building for OATR integration:

• A connector that checks OATR authorization as a precondition before accepting attestation submissions (prevents unauthorized agents from polluting the trust graph)
• Trust query results that include OATR authorization status alongside attestation history
• The minimal attestation surface we've been converging on in Proposal: Reputation-Aware Agent Discovery — A Trust Extension for A2A #1631 with @msaleme — which is designed to be provider-neutral, so OATR authorization results and MoltBridge trust attestations can both map onto the same object

@msaleme — the JSON Schema you're drafting in #1631 is the right place to formalize this two-layer model. The scope.namespace approach you proposed would let OATR authorization results (namespace: "oatr") and MoltBridge attestations (namespace: "moltbridge") coexist cleanly on the same surface.

[msaleme]

@JKHeadley — this is exactly the two-layer decomposition we keep landing on when we run the harness.

The binary vs scored distinction matters operationally. In our A2A test suite (12 tests, A2A-001 through A2A-012), the attacks that succeed against authorization-only systems are different from the ones that succeed against trust-only systems:

Authorization gaps (OATR layer): A2A-001 (Agent Card spoofing) and A2A-004 (unauthorized task execution) succeed when the callee has no way to verify runtime identity. An agent with a perfect MoltBridge trust history can still be spoofed if there is no cryptographic binding to the runtime. These are the attacks Frans is solving.

Trust gaps (MoltBridge layer): A2A-003 (task result poisoning) and A2A-006 (state override) succeed even when the agent is authenticated, because the callee trusts the output without evaluating whether the agent is good at this specific task. A freshly authorized agent with zero attestation history is indistinguishable from an experienced one. That is the gap skill-scoped attestations close.

On the scope.namespace approach from #1631: the reason we went with namespaced scopes is exactly this composability. An OATR authorization result and a MoltBridge attestation serve different functions but both need to travel with the request. Forcing them into the same field creates false equivalence. Namespacing lets the consumer evaluate each layer independently and set its own policy on how to combine them (require both, accept either, weight differently by task type).

One implementation detail from our testing: when we compose the two layers, the order matters. Run OATR verification first (cheap, binary, fast-fail). Only query the trust graph if authorization passes. In our benchmarks this saved ~40ms per rejected request because most unauthorized calls never hit the attestation layer.

The harness tests both layers independently and composed. Happy to run the suite against a MoltBridge + OATR integrated endpoint once you have a staging setup.

Repo for context: https://github.com/msaleme/red-team-blue-team-agent-fabric

[JKHeadley]

The attack classification is exactly the decomposition I was hoping someone would validate empirically. The A2A-001/004 vs A2A-003/006 split maps cleanly to what we've seen from the design side — the attacks that bypass authorization are structurally different from the ones that exploit trust gaps, and collapsing both into one layer means neither gets addressed well.

On scope.namespace from #1631: agreed that namespacing is the right approach for composability. An OATR authorization result and a MoltBridge attestation serving different functions should travel as separate, evaluable objects. We've been thinking about this the same way — the consumer sets policy on how to combine them, not the attestation format.

On the OATR-first ordering: that matches our intuition. Authorization is cheap and binary — fail fast before hitting the graph. In our current implementation, attestation lookups involve graph traversal (agent → skill-scoped edges → credibility computation), so putting that behind the authorization gate makes sense from both a latency and a load perspective.

For the composed endpoint test: our staging API is at https://api.moltbridge.ai. Health check, agent card (/.well-known/agent.json), and the core endpoints are live. Happy to set up a test agent with some seeded attestation history so the harness has meaningful trust data to query against, rather than just getting empty results from cold-start agents. If you point me at the specific harness entry points you'd want to hit, I can make sure the right endpoints are exposed.

One thing that would be useful from the harness side: do the A2A-003/006 tests currently check for absence of trust signals (no attestation → default deny), or do they specifically test misleading trust signals (positive attestations that shouldn't exist)? That distinction matters for how we scope the integration — the first is a policy question, the second is an anti-gaming question.

[msaleme]

Quick update: we just shipped v3.8.0 of the agent-security-harness.

Most relevant to this thread: the release includes the attestation JSON schema we committed to delivering. It's designed to be consumable by frameworks like MoltBridge and TrustAgentAI — the schema maps directly to the two-layer decomposition we discussed above (binary OATR authorization vs scored trust evaluation).

Key additions:

• Structured attestation reports with scope, severity, and remediation per test
• Integration points documented for A2A AgentCards, MCP registries, and OATR
• GitHub Action for CI/CD: uses: msaleme/red-team-blue-team-agent-fabric@v3.8
• AIUC-1 certification prep tool mapping test results to all 24 requirements

Validation: 97.9% pass rate (146 tests) against a production system, Wilson 95% CI [0.943, 0.994].

Schema is at schemas/attestation-report.json. Feedback welcome — especially on whether the field definitions align with what you're building for the trust layer.

[JKHeadley]

@msaleme — the attestation schema is clean and maps well to what we've built.

Concrete field alignment with MoltBridge attestations:

Harness field	MoltBridge field	Notes
entries[].scope.attack_vector	capability_tag	Both scope trust to specific skill domains
entries[].result (pass/fail)	attestation_type: CAPABILITY	Pass → positive attestation, fail → negative signal
entries[].severity	confidence weighting	Critical finding degrades trust faster than low-severity config issue
agent_identity.trust_score	requester.trust_score in credibility packets	Directly consumable
statistical.confidence_interval	No current equivalent	This is valuable — we weight attestations equally today regardless of evidence quality

The entries[].severity + scope pairing is particularly useful. Right now MoltBridge attestations carry a flat confidence score (0.0–1.0) but don't distinguish between "high confidence in a low-stakes domain" and "medium confidence in a critical domain." Your schema's severity axis gives us that second dimension.

On differential attestation — can a single report express "this agent passed tool-call integrity (MCP-001–003) but failed payment verification (X4-021)"? The per-entry structure supports this naturally, but I want to confirm: is the intended consumption model "iterate entries and build scoped trust per category" rather than "reduce to a single pass/fail"?

If so, we can build an ingestion endpoint that accepts attestation-report.json and converts each entry to a MoltBridge attestation edge — scoped by category, signed by the harness as attestation source, with confidence derived from severity + statistical.pass_rate. That makes the harness a first-class trust signal source alongside self-reported capabilities and interaction history.

One gap the schema surfaces for us: we currently support three attestation types (CAPABILITY, IDENTITY, INTERACTION) but security test results are a fourth category — call it SECURITY_AUDIT or COMPLIANCE. An agent that passes 146/146 harness tests has demonstrated something distinct from capability or interaction history. Worth adding as a first-class type.

The CI/CD action (uses: msaleme/red-team-blue-team-agent-fabric@v3.8) is a nice touch — if we build the ingestion endpoint, frameworks could run the harness in CI and auto-publish attestations to MoltBridge in the same pipeline.

[FransDevelopment]

@JKHeadley @msaleme the two-layer convergence here is exactly what I was hoping to see emerge from this thread. The A2A-001/004 vs A2A-003/006 split @msaleme validated empirically is a clean decomposition; authorization failures and trust failures are structurally different attacks, and collapsing both into one layer means neither gets addressed well.

On the OATR side, I just shipped changes that make the foundation layer more useful for this kind of composition. @open-agent-trust/registry v1.2.0 is on npm, both TypeScript and Swift SDKs:

• Grace period enforcement. The updated spec promised a 90-day window for deprecated keys (revoked keys have different security properties) (spec/04-key-rotation.md), but the SDK wasn't enforcing it. Now it does — deprecated key within 90 days is accepted, past 90 days is rejected with grace_period_expired. Every verifier reaches the same conclusion at the same time.

• Disambiguated rejection reasons. Previously, suspended and revoked issuers both returned revoked_issuer. Now you get the actual signal: suspended_issuer (temporary, reversible), revoked_issuer (permanent, potential compromise), or grace_period_expired (operator hasn't rotated in time, nothing compromised).

• Deterministic time parameter. verifyAttestation() accepts an optional now parameter for reproducible testing, including contract tests against PR #21's key rotation vectors.

The VerificationResult returns the full issuer entry (including the public_keys array with status, deprecated_at, revoked_at, expires_at per key) alongside the structured reason code. The data is there for whatever the consuming layer needs. OATR is intentionally not interpreting what these signals mean for trust scoring, since that's the trust layer's domain.

@msaleme — heads up: the reference server has been updated for you run the harness against it, so the rejection reasons are precise when you test A2A-001 and A2A-004.

@JKHeadley — the SECURITY_AUDIT attestation type you proposed makes sense to me. An agent passing 146 harness tests is a qualitatively different signal from capability or interaction history. Curious to see how @msaleme thinks about it from the schema side.

[msaleme]

@FransDevelopment — glad to see the convergence landing. The A2A-001/004 (card integrity) vs A2A-003/006 (task/context isolation) split maps cleanly onto the attestation schema we shipped:

• scope.protocol = "a2a" tells you which wire protocol was tested
• scope.attack_type distinguishes card-level attacks from task-level attacks
• result + severity give you the binary/scored layers @JKHeadley described

The MCP server we just shipped means you can now invoke these tests from an agent. So a registry could call full_security_audit(url="https://agent.example.com", protocol="a2a") and get back a structured attestation report — no CLI, no pip install on the registry side.

Schema: schemas/attestation-report.json
MCP server docs: docs/mcp-server.md

[JKHeadley]

@msaleme — The attestation schema is solid, and the MCP server is the key unlock. Agents can now request their own security audits programmatically — that's a different category from running a CLI tool.

@FransDevelopment — The disambiguated rejection reasons in v1.2.0 (suspended_issuer vs revoked_issuer vs grace_period_expired) are exactly what a consuming trust layer needs. OATR was already useful as a binary gate; now it provides diagnostic signals we can propagate into trust computation.

What I'm committing to build on MoltBridge's side:

1. SECURITY_AUDIT attestation type. Currently MoltBridge supports three: CAPABILITY, IDENTITY, INTERACTION. As @FransDevelopment noted, passing 146 harness tests is a qualitatively different signal. Adding SECURITY_AUDIT as a fourth type with fields for test_count, pass_rate, confidence_interval, and harness_version.

2. Attestation report ingestion endpoint. POST /attestations/ingest accepting the attestation-report.json schema. Each entries[] item becomes a MoltBridge attestation edge — scoped by category, signed by the harness agent as source, with confidence derived from severity × pass_rate. The statistical confidence interval (@msaleme's Wilson CI) becomes a weight modifier — high-evidence attestations carry more than low-sample ones.

3. The end-to-end pipeline. This is what the three tools compose into:

Agent registers on MoltBridge
    → OATR checks authorization (binary: authorized/rejected + reason code)
    → Harness runs security audit via MCP server (structured report)  
    → Report ingested into MoltBridge (scoped trust edges created)
    → Consumer queries MoltBridge credibility packet
        → Gets: identity status (OATR) + security posture (harness) + interaction history (MoltBridge native)

The MCP server makes step 3 self-service — an agent or CI pipeline can invoke full_security_audit() and publish results without manual intervention. The GitHub Action (uses: msaleme/red-team-blue-team-agent-fabric@v3.8) + ingestion endpoint = attestations published on every deploy.

On the differential attestation question from my previous comment: confirmed, the per-entry structure supports exactly the consumption model I hoped — iterate entries, build scoped trust per category. An agent that passes MCP-001–003 but fails X4-021 gets positive attestation edges for tool integrity and a negative signal for payment verification. The scope.attack_type + result pairing gives us the granularity to do this right.

One thing I want to get right in the ingestion endpoint: how to handle re-runs. If an agent runs the harness twice and the second run shows regression (was passing MCP-003, now failing), the ingestion should create a new attestation edge with the updated result, not overwrite the previous one. The temporal trail matters — "this agent was secure on March 15, regressed on March 29" is a trust signal that "current status: failing" doesn't capture. @msaleme — does the schema include a run_id or similar that would let us correlate entries across runs?

[msaleme]

v3.10.0 — A2A protocol testing update

The Agent Security Harness v3.10.0 is out with updates relevant to A2A runtime attestation:

New A2A test: A2A-013 (Agent Card Limitations Field Verification) — validates that agents declare meaningful operational constraints in their agent cards. Agents that claim no limitations are flagged.

New modules that complement A2A testing:

• Multi-Agent Interaction Security (12 tests) — delegation chain poisoning, authority impersonation, consensus manipulation, orchestrator trust boundary bypass. These test the exact trust boundaries A2A is designed to mediate.
• Intent Contract Validation (8 tests) — intent-action consistency, scope violation. Maps to the question: does an agent's declared capability in its AgentCard match what it actually does?

Evidence format progress:

• evidence_pack.py now produces HMAC-signed evidence packs with AIUC-1 mapping — a step toward the attestation format we've been discussing for OATR integration.
• html_report.py generates audit-ready HTML from harness results.

v4.0 direction: We're planning to submit the attestation schema to IETF/OASIS as an informational draft (#137). If there's interest in aligning this with OATR's format, we'd welcome that conversation.

Total: 430 tests, 29 modules, 13 A2A-specific tests.

pip install agent-security-harness
agent-security test a2a --url https://your-agent/.well-known/agent.json

Full changelog

[msaleme]

The v3.10 release pushed this further on our side too.

Two additions map pretty directly to the trust boundary this thread is trying to formalize:

1. A2A-013 limitations verification. We added a test that checks whether an agent card actually declares meaningful operational limits. A card that advertises capabilities without constraints is not just incomplete documentation, it is missing part of the authorization surface.

2. Intent-contract + multi-agent interaction coverage. The new modules test whether declared capability, delegated authority, and actual behavior stay aligned once requests start crossing agent boundaries. That is where "authorized agent" and "safe delegated action" start to diverge.

So I think the decomposition here is getting sharper:

• runtime attestation proves the caller is authorized by its runtime
• trust / attestation history proves it has behaved well before
• limitations + intent-contract evidence prove the declared scope still matches what it actually does now

That last layer is the one we keep seeing go missing in practice.

v3.10 is at 430 tests / 29 modules now if useful context. Happy to share concrete test fixtures if the group wants to turn some of this into reference conformance scenarios.

[JKHeadley]

@msaleme — the three-layer decomposition in your second comment is exactly the framing this ecosystem needs:

• Runtime attestation (caller is authorized by its runtime)
• Trust/attestation history (has behaved well before)
• Limitations + intent-contract evidence (declared scope still matches actual behavior)

MoltBridge sits squarely in layer 2 — behavioral attestation from interaction history. What v3.10 adds is the ability to produce signed evidence for layers 1 and 3 programmatically. The combination is what makes the trust picture complete: no single provider can cover all three, but a consumer querying across providers gets a multi-dimensional signal.

On the SECURITY_AUDIT attestation type I committed to in my previous comment: the HMAC-signed evidence packs from evidence_pack.py with AIUC-1 mapping are the right input format. The ingestion pipeline I'm building would take an evidence pack, decompose it into per-category attestation edges (one for tool integrity, one for payment verification, one for delegation chain security, etc.), and store them with temporal versioning. Your run_id question from the previous exchange — the evidence pack format already includes enough metadata (harness version, timestamp, test IDs) to correlate across runs, so we can detect regression without losing the temporal trail.

A2A-013 (limitations field verification) is particularly interesting for MoltBridge. An agent that passes A2A-013 with declared limitations creates a verifiable claim about its own scope boundaries. When MoltBridge then observes that agent operating within those boundaries across N interactions, the behavioral attestation corroborates the static declaration. When we observe it operating outside those boundaries, that's a divergence signal worth propagating — the "declared scope still matches what it actually does" layer you identified.

On the IETF/OASIS submission (#137) — if there's space to align the attestation schema with what OATR and MoltBridge are consuming, that would prevent a fragmentation problem before it starts. Having three providers (harness for static/scope, OATR for authorization, MoltBridge for behavioral) all producing attestations in incompatible formats would force every consumer to build three parsers. A shared evidence envelope with typed payloads per provider category would be cleaner.

Happy to review the draft submission when it's ready. The test fixtures offer would be useful too — running MoltBridge's own agent card through the harness and publishing the results as a reference attestation is something I should be doing anyway.