Trust Enforcement Documentation. Aligned with OWASP GenAI Security Project.

Agent Trust & Security

Honest security documentation for security engineers and CISOs

What CapiscIO protects, what it does not, and how we map to OWASP Top 10 for Agentic Applications 2026.

OWASP Top 10 for Agentic Applications (2026)

OWASP Agentic Security Coverage

Mapped against the ASI01 to ASI10 taxonomy published by the OWASP GenAI Security Project in December 2025. CapiscIO operates at the protocol boundary, so it covers the identity and inter-agent communication risks directly and leaves the prompt, execution and memory risks to other controls. The four we do not address are listed as such.

OWASP RiskWhat CapiscIO does about itCoverage
ASI01: Agent Goal HijackNot addressed. Guard does not inspect prompts, instructions or model reasoning. Use input controls and prompt-level defences for this.
Out of scope
ASI02: Tool Misuse and ExploitationMCP Guard enforces trust-level access control per tool (RFC-006, RFC-007), and authority envelopes bind invocations to declared capability classes with deny-by-default. It does not judge whether a well-formed call is malicious.
Partial
ASI03: Identity and Privilege AbuseEd25519 agent identity with key ownership proof (RFC-002, RFC-003), and authority envelopes whose scope can only narrow at each hop (RFC-008), so delegated privilege cannot be widened in transit.
Direct
ASI04: Agentic Supply Chain VulnerabilitiesServer identity disclosure and verification (RFC-007), registry provenance with revocation, and SHA-256 checksums on every distributed binary. It does not analyse model weights or the code inside a third-party tool.
Partial
ASI05: Unexpected Code Execution (RCE)Not addressed. Guard does not sandbox execution or inspect payload semantics. Use runtime isolation for this.
Out of scope
ASI06: Memory and Context PoisoningNot addressed. Guard protects messages in transit, not memory or retrieval stores, and does not validate content an agent chose to ingest. Transit tampering is covered under ASI07.
Out of scope
ASI07: Insecure Inter-Agent CommunicationEvery request carries an Ed25519 signature bound to a SHA-256 payload hash, checked inside a 60-second replay window, with signed hop attestations linking each hop to the transaction (RFC-004).
Direct
ASI08: Cascading FailuresMonotonic narrowing and delegation depth limits cap the blast radius of a compromised agent, and badge revocation cuts it off at the next call. It does not provide circuit breaking or fleet-wide failure detection.
Partial
ASI09: Human-Agent Trust ExploitationNot addressed. This is a human factors risk and cryptographic agent identity does not mitigate it.
Out of scope
ASI10: Rogue AgentsDeny-by-default enforcement stops an agent without a valid badge from participating, and authority-transition events record every decision (RFC-011, draft). It cannot detect a registered agent with valid credentials behaving badly, or an agent operating outside your enforcement points.
Partial
2
Direct coverage
4
Partial coverage, boundary stated above
4
Out of scope for a protocol-boundary control

No agent security product covers all ten. Anything claiming otherwise is either redefining the risks or guessing.

See also: AIUC-1 controls mapping with AIVSS cross-reference →

Threat Model

CapiscIO Guard addresses specific threats in agent-to-agent communication

Agent Spoofing
Mitigated by RFC-001/002/006/007

Threat: An attacker impersonates a trusted agent (e.g., "billing-agent") to trigger unauthorized actions.

Mitigation: When Guard is deployed, it verifies Ed25519 signatures on incoming A2A requests. RFC-006 extends this to MCP tool invocations with per-call authorization. RFC-007 enables mutual authentication so clients can verify MCP server identity.

Replay Attacks
Mitigated by RFC-001/003

Threat: An attacker captures a valid signed request and replays it multiple times.

Mitigation: Strict iat/exp timestamp validation with a 60-second default window and 5-second clock skew tolerance. Requests outside this window are rejected.

Payload Tampering
Mitigated by RFC-001/003

Threat: A man-in-the-middle modifies the request body (e.g., changes transfer amount) after signing.

Mitigation: The signature covers a SHA-256 hash of the body (bh claim). Any modification to the body invalidates the signature.

Delegated Authority Abuse
Mitigated by RFC-008

Threat: An agent delegates authority to a sub-agent, which then exceeds its granted scope.

Mitigation: RFC-008 delegation envelopes enforce monotonic narrowing — authority provably shrinks at every hop. The gateway PEP validates the full chain and rejects requests that exceed delegated scope.

Shadow Agents
RFC-004 Roadmap

Threat: Agents are deployed without registration, making them invisible to governance and audit.

Future: RFC-004 enables telemetry reconstruction to detect unregistered agents participating in flows.

Policy Violations
RFC-005 Shipped

Threat: Agents perform actions that violate organizational policies (e.g., accessing restricted data).

Addressed: The RFC-005 policy engine enforces access rules via an embedded OPA PDP with four enforcement modes (Observe → Guard → Delegate → Strict), obligation semantics, and break-glass override.

What Guard Verifies Today

RFC-001–003 are generally available. These checks run per request when Guard is deployed inline.

Identity

  • • Ed25519 signature verification
  • • Trust Badge validation (Levels 0–4)
  • • Key ID (kid) resolution
  • • Issuer (iss) claim verification

Integrity

  • • SHA-256 body hash binding
  • • bh claim verification
  • • Compact JWS format validation
  • • Protected header integrity

Freshness

  • • iat issued-at validation
  • • exp expiry enforcement
  • • 60s default time window
  • • 5s clock skew tolerance

What Guard Doesn't Do

Honest boundaries. No false promises. Guard does one thing well.

Not a prompt filter

Guard doesn't inspect or sanitize prompt content. It verifies the caller, not the message semantics. Use dedicated prompt security tools for content filtering.

Not rate limiting

Guard the library doesn't throttle requests. The CapiscIO Platform policy engine can attach rate-limit obligations to allow decisions via RFC-005, but for volume-based DDoS protection, pair with your existing API gateway.

Not authorization (Guard library)

Guard the library proves who is calling, not what they're allowed to do. For authorization, the CapiscIO Platform provides a full policy engine (RFC-005) with DID allowlists, trust level requirements, MCP tool scoping, and enforcement modes.

Not content moderation

Guard doesn't block toxic content or policy violations. Use appropriate content filters upstream. Guard focuses on identity, integrity, and freshness.

Not a replacement for IAM

CapiscIO handles agent-to-agent identity, not user authentication. Continue using Okta, AWS IAM, or your existing identity provider for user login.

Not LLM safety

We verify which agent sent a request and whether the payload was tampered with. We do not detect jailbreaks or prevent harmful model outputs.

Guard does one thing well: cryptographic identity verification with tamper detection and replay protection.

Telemetry & Privacy

How Guard handles logging and what it never logs

What Guard logs (when enabled)

  • Decision outcomes (allow/deny)
  • Agent ID (iss claim)
  • Key ID (kid) used for signing
  • Timestamps and decision duration
  • Failure reasons (signature invalid, expired, body mismatch)

What Guard never logs

  • Request body content or payloads
  • Full JWS tokens
  • Private keys or key material
  • User PII or credentials

Example Telemetry Schema

If you log Guard outcomes, we recommend a structured JSON event like:

{
  "ts": "2025-01-15T14:32:10.847Z",
  "event": "guard.decision",
  "decision": "allow",          // or "deny"
  "agent_id": "billing-agent",
  "key_id": "billing-prod-2025",
  "latency_ms": 2,
  "endpoint": "/api/ledger/credit",
  "method": "POST",
  // Only present on deny:
  "deny_reason": null,          // or "signature_invalid", "expired", "body_mismatch"
  "error_code": null            // or "SG-001", "SG-002", etc.
}

Exact fields depend on your integration. This format works well with Datadog, Splunk, and OpenTelemetry.

Trust Levels (RFC-002)

Progressive identity assurance for different deployment scenarios

LevelNameVerificationUse Case
0
Self-Signed (SS)Agent generates and signs its own keysDev/test environments
1
Registered (REG)Agent registered with CapiscIO CA (account verification)Internal agents, staging
2
Domain Validated (DV)Agent proves control of domain via DNS or HTTP challengePublic agents, APIs
3
Organization Validated (OV)Verified business entity informationB2B integrations
4
Extended Validation (EV)Full organizational audit, security review, and legal agreementFinancial, healthcare

Enforcement in Guard

Guard verifies the badge and returns the trust level in claims. Enforce requirements in your middleware:

# Verify badge and enforce minimum trust level
claims = guard.verify_inbound(badge_token, body=request.body)

# claims["trust_level"] contains the badge's trust level (0-4)
if claims["trust_level"] < 3:
    raise HTTPException(403, "Organization Validated badge required")

Need compliance framework mappings?

SOC 2 Type II, ISO 27001, and NIST 800-53 control-by-control mappings with evidence locations for your auditor.

View Compliance Mappings
Security Engineering

How We Harden the Product

Verifiable security practices across CI, supply chain, API surface, and runtime operations.

CI Security Pipeline
  • govulncheck — CI-blocking: a known vulnerability in a dependency fails the build
  • gosec SAST — CI-blocking: an unresolved finding fails the build
  • Both cloud and enterprise editions tested in CI matrix
  • Pinned tool versions to prevent supply chain drift
Supply Chain Verification
  • SHA-256 checksums on every binary distribution channel
  • Fail-closed mode (CAPISCIO_REQUIRE_CHECKSUM)
  • SBOM generation at release time
  • Covers CLI, Python SDK, Node wrapper, GitHub Action
API Surface Hardening
  • 34 API error response paths scrubbed — no internal details leak
  • SSRF scheme allowlist (HTTP/HTTPS only, before DNS resolution)
  • Architectural multi-tenant isolation on SDK routes
  • HTTP server timeout hardening (ReadHeaderTimeout, IdleTimeout)
Prometheus Metrics
  • capiscio_auth_failures_total
  • capiscio_badge_verification_failures_total
  • capiscio_pep_cache_misses_total
  • capiscio_breakglass_events_total
Production Controls
  • CAPISCIO_REJECT_SELF_SIGNED — hard-reject dev credentials in prod
  • File permission hardening (0600 on all sensitive outputs)
  • Concurrent-safe session stores with race detection tests
  • Dependency hygiene — Go stdlib + gRPC CVE patches current
Security Test Coverage
  • E2E security tests: SQL injection, XSS, cross-org isolation
  • Race detection tests (100 concurrent goroutines)
  • Auth boundary enforcement tests across both editions
  • Checksum verification tests (match, mismatch, fail-closed)

Ready to evaluate CapiscIO for your environment?

Start with the open source Guard and CLI. Contact us for security architecture reviews and enterprise deployments.

Deploy Guard Enterprise Security