Aligned with OWASP Agentic Security Initiative

Security & Trust

Transparent security guarantees for security engineers and CISOs

What CapiscIO protects, what it doesn't, and how we map to OWASP Agentic Top 10.

OWASP Agentic Top 10 (2025)

OWASP Agentic Top 10 Coverage

How CapiscIO Guard addresses the OWASP Agentic Security threats

OWASP Risk	Description	CapiscIO Coverage
AG01: Agent Identity Spoofing	Attacker impersonates a trusted agent	Direct
AG02: Tool Misuse	Agents invoke tools with malicious parameters	Partial
AG03: Privilege Escalation	Agent gains unauthorized permissions	Roadmap
AG04: Resource Exhaustion	Runaway agents consume excessive resources	-
AG05: Insufficient Sandboxing	Agents escape execution boundaries	-
AG06: Communication Tampering	Inter-agent messages modified in transit	Direct
AG07: Replay Attacks	Valid requests captured and repeated	Direct
AG08: Model Inversion	Extracting training data via queries	-
AG09: Prompt Injection	Malicious inputs hijack agent behavior	-
AG10: Audit Trail Gaps	Missing or insufficient logging	Direct

Direct coverage

On roadmap

Out of scope (use defense-in-depth)

Threat Model

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

Agent Spoofing

Mitigated by RFC001-002

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

Mitigation: Every request must include a valid Ed25519 signature from a registered keypair. Signature verification fails if the private key is not held by the claimed agent.

Replay Attacks

Mitigated by RFC001-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 RFC001-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

RFC004 Roadmap

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

Future: RFC004 introduces chain-of-custody tracing to verify delegation chains and detect missing or unauthorized hops.

Shadow Agents

RFC004 Roadmap

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

Future: RFC004 enables telemetry reconstruction to detect unregistered agents participating in flows.

Policy Violations

RFC005 Planned

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

Planned: RFC005 introduces policy bundles with obligations, allowing declarative enforcement of access rules.

What Guard Verifies Today

RFC001–003 are generally available. These checks run on every request.

Identity

• Ed25519 signature verification
• Trust Badge validation (IAL-0, IAL-1)
• 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 doesn't throttle requests. Pair with your existing API gateway, Kong, Envoy, or rate limiter for request volume controls.

Not authorization

Guard proves who is calling, not what they're allowed to do. Authorization is your business logic. Guard handles authentication.

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 (only signature prefix for debugging)
Private keys or key material
User PII or credentials

Canonical Telemetry Schema

Every Guard decision emits a structured log with this schema:

{
  "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.
}

This format is compatible with Datadog, Splunk, and OpenTelemetry. No payload content is included.

Trust Levels (RFC-002)

Progressive identity assurance for different deployment scenarios

Level	Name	Verification	Use Case
0	Self-Signed (SS)	Agent generates and signs its own keys	Dev/test environments
1	Domain Validated (DV)	Agent proves control of domain via DNS or HTTP challenge	Public agents, APIs
2	Organization Validated (OV)	Verified business entity information	B2B integrations
3	Extended Validation (EV)	Full organizational audit and verification	Financial, healthcare
4	Community Vouched (CV)	Web-of-trust vouching from verified agents	Open ecosystems

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-3)
if claims["trust_level"] < 2:
    raise HTTPException(403, "Organization Validated badge required")

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