Hi — I'm working on OM World, a protocol for a decentralized intent economy. Capiscio's framing — runtime security middleware for A2A — sits right at the seam between two primitives we're specifying (Agent Mandate and Execution Proof). The "always-on validation" framing is more disciplined than what most agent frameworks ship with.
Three design questions where your experience would be valuable:
1. What's actually inside the validation envelope at runtime?
Signature verification + rate limiting is the easy half. Does Capiscio also do semantic validation — "is this call within the agent's declared scope, against an authorized tool, using inputs that match the mandate constraints"? Or is semantic scope-checking left to the application layer?
We're trying to figure out how thick the runtime guard should be vs. how much should be encoded in the signed mandate and verified offline.
2. Identity verification: against what?
When verifying an A2A signature, what's the source-of-truth for the agent's public key — the agent card you fetched on first contact, an on-chain identity registry (DID, ERC-8004), or a configured allowlist? The choice affects whether identity rotation requires re-trusting and whether a compromised agent card can impersonate.
3. Failure-mode policy
When validation fails — hard reject (drop and notify), soft escalate (allow + warn for human review), or quarantine (capture call for post-hoc audit)? And is this configurable per agent / per call class, or fixed at SDK level?
This connects to our Execution Proof's dispute semantics — we have severity tiers (fabricated step = 100% slash, latency breach ≤ 10%) and I'm curious whether your runtime classification maps to anything similar at the dispute layer.
Thanks for building this — the "always-on" framing alone is the right philosophical posture for the space.
Hi — I'm working on OM World, a protocol for a decentralized intent economy. Capiscio's framing — runtime security middleware for A2A — sits right at the seam between two primitives we're specifying (Agent Mandate and Execution Proof). The "always-on validation" framing is more disciplined than what most agent frameworks ship with.
Three design questions where your experience would be valuable:
1. What's actually inside the validation envelope at runtime?
Signature verification + rate limiting is the easy half. Does Capiscio also do semantic validation — "is this call within the agent's declared scope, against an authorized tool, using inputs that match the mandate constraints"? Or is semantic scope-checking left to the application layer?
We're trying to figure out how thick the runtime guard should be vs. how much should be encoded in the signed mandate and verified offline.
2. Identity verification: against what?
When verifying an A2A signature, what's the source-of-truth for the agent's public key — the agent card you fetched on first contact, an on-chain identity registry (DID, ERC-8004), or a configured allowlist? The choice affects whether identity rotation requires re-trusting and whether a compromised agent card can impersonate.
3. Failure-mode policy
When validation fails — hard reject (drop and notify), soft escalate (allow + warn for human review), or quarantine (capture call for post-hoc audit)? And is this configurable per agent / per call class, or fixed at SDK level?
This connects to our Execution Proof's dispute semantics — we have severity tiers (fabricated step = 100% slash, latency breach ≤ 10%) and I'm curious whether your runtime classification maps to anything similar at the dispute layer.
Thanks for building this — the "always-on" framing alone is the right philosophical posture for the space.