Agent Trust Profile¶

Level: Advanced preview extension

Simple explanation¶

Agent Trust applies SD-JWT selective disclosure to the problem of AI agent authorization.

What you will learn¶

• Why API keys and broad OAuth scopes are insufficient for AI agents
• How capability tokens encode per-action, per-resource permissions
• How delegation chains let one agent authorize another
• The relationship between Agent Trust Profile and Agent Trust Kits

Before Agent Trust: An AI agent calls a tool with a broad API key. The tool cannot distinguish what the agent is allowed to do, who authorized it, or whether the request is legitimate.

After Agent Trust: The agent presents a scoped capability token (an SD-JWT) that says exactly what it can do, who delegated the permission, and when it expires. The tool verifies the token before executing.

How it compares¶

Problem Statement¶

AI agents and automation services increasingly call tools, APIs, and other agents on behalf of users or workflows. Traditional service accounts and broad API keys are difficult to constrain per action, hard to audit, and risky when an agent is compromised or misdirected.

Agent Trust is a preview .NET extension that explores how SD-JWT, key binding, policy, and selective disclosure can support scoped agent delegation and MCP/API tool governance. It complements existing OAuth, mTLS, API gateway, and MCP authorization patterns; it does not replace them.

When to use Agent Trust¶

OAuth and Agent Trust: complements, not competitors¶

Agent Trust does not replace OAuth. It layers on top of it:

A typical deployment uses OAuth to authenticate the agent, then Agent Trust to constrain what the authenticated agent can do at the individual tool-call level.

Threat Model¶

Token Model¶

An Agent Trust capability token is an SD-JWT minted for a specific action. The token is short-lived and contains only the claims needed by the target tool or agent. The canonical token type is agent-cap+sd-jwt.

Capability Claims¶

The cap claim carries the machine-enforceable authority:

{
  "tool": "member.lookup",
  "toolId": "tool-registry://member-lookup-v2",
  "action": "read",
  "resource": "member/12345",
  "limits": {
    "maxResults": 10,
    "maxPayloadBytes": 32768
  },
  "delegationDepth": 0
}

The ctx claim carries correlation and classification metadata:

{
  "correlationId": "abc123",
  "workflowId": "wf-claims-process",
  "stepId": "step-3-lookup",
  "tenantId": "tenant-contoso",
  "dataClassification": "confidential"
}

Receivers must verify the token before trusting any claim. Application code remains responsible for enforcing resource-specific limits that cannot be enforced by cryptography alone.

Key Binding and Proof-of-Possession¶

Capability tokens may include sender constraints through cnf claims. Deployments can bind tokens to:

• DPoP proof keys (single or dual binding)
• mTLS client certificates
• SD-JWT key binding
• workload identity keys
• gateway-managed proof material

flowchart LR
    Token[Capability Token] --> CNF[cnf claim]
    CNF --> DPoP[DPoP Proof]
    CNF --> MTLS[mTLS Certificate]
    CNF --> KB[SD-JWT Key Binding]
    DPoP --> Verify[Verifier checks\nkey possession]
    MTLS --> Verify
    KB --> Verify

Sender constraints are recommended for privileged actions and cross-boundary tool calls. The IDpopProofValidator and IMtlsSenderConstraintValidator interfaces provide extensible PoP validation.

Nonce And Replay Protection¶

Receivers should reject reused jti values within the token lifetime plus configured clock skew. Multi-instance deployments need a distributed nonce store, not the in-memory development implementation.

Default posture:

• Short token lifetimes
• Fail closed for privileged actions
• Distributed replay storage in production-like pilots
• Clock skew kept small and explicit

Delegation Constraints¶

Agent-to-agent delegation must preserve or narrow authority. A delegated capability must not exceed the original token's action, resource, audience, lifetime, or delegation depth.

The AttenuationValidator enforces the following narrowing rules at each delegation hop:

flowchart TD
    Parent[Parent Capability] --> Check1{Lifetime <= parent?}
    Check1 -->|Yes| Check2{Tool matches?}
    Check1 -->|No| Reject[Reject: lifetime exceeded]
    Check2 -->|Yes| Check3{Action narrowed?}
    Check2 -->|No| Reject2[Reject: tool mismatch]
    Check3 -->|Yes| Check4{Resource narrowed?}
    Check3 -->|No| Reject3[Reject: action escalation]
    Check4 -->|Yes| Check5{Depth < maxDepth?}
    Check4 -->|No| Reject4[Reject: resource escalation]
    Check5 -->|Yes| Check6{rootIssuer consistent?}
    Check5 -->|No| Reject5[Reject: depth exceeded]
    Check6 -->|Yes| Accept[Accept delegation]
    Check6 -->|No| Reject6[Reject: root issuer mismatch]

Required constraints:

• Maximum delegation depth enforced by maxDepth
• No privilege expansion across hops (attenuation validation)
• Explicit allowed downstream audiences
• Correlation ID propagation across chain
• rootIssuer must remain consistent through the chain
• Receipt emitted at each hop

MCP Usage¶

SdJwt.Net.AgentTrust.Mcp treats MCP as one adapter target. The profile does not assume MCP is the only agent transport or authorization model.

For MCP tool calls:

1. The client interceptor evaluates policy before the call.
2. A capability token is minted for the requested tool/action.
3. The token is attached using the deployment's chosen metadata or HTTP header convention.
4. The server guard verifies signature, audience, expiry, replay status, and capability claims.
5. The tool enforces application-level constraints and emits an audit receipt.

ASP.NET Core API Usage¶

SdJwt.Net.AgentTrust.AspNetCore provides inbound middleware and authorization helpers for APIs that receive capability tokens. APIs should still use normal transport security, authentication boundaries, and resource authorization. Agent Trust adds per-action capability proof and audit context.

OpenTelemetry Audit Model¶

Agent Trust receipts should include:

• Token ID (jti)
• Issuer and audience
• Tool and action
• Decision (Permit, Deny, Indeterminate)
• Reason code
• Correlation ID
• Policy ID, version, and hash (pol_bind)
• Evaluation duration
• Receipt partition key (tenantId, date, issuer)
• Obligations (post-decision actions the caller must fulfill)

Receipts should avoid raw sensitive payloads. Use hashes, references, or selective disclosure when the receiver does not need full context.

Metrics (per spec Section 24.1)¶

The AgentTrustMetrics class exposes spec-aligned counters and histograms:

Security Modes¶

Agent Trust supports three security modes via AgentTrustSecurityMode:

Security Considerations¶

• Agent Trust is a preview project profile, not a completed external standard.
• Do not treat capability tokens as a substitute for TLS, OAuth resource-server protections, or API authorization.
• Keep signing keys in KMS/HSM-backed custody for serious pilots.
• Use constant-time comparisons for sensitive token material.
• Reject weak algorithms and follow the repository HAIP algorithm policy (ES256/384/512, PS256/384/512).
• Use request binding (req_bind) to prevent token reuse across different requests.
• Use attenuation validation for all delegation chains to prevent privilege escalation.
• Validate the deployment threat model before using these packages beyond evaluation or pilot environments.

Standards Relationship¶

Related concepts¶

• Agent Trust Kits
• Agent Trust Integration Guide
• MCP Trust Demo
• Package Maturity