Security Considerations

This page covers security considerations for implementing and deploying Agent Auth. For the full treatment, see §8 Security Considerations in the specification.

Private keys

Private keys must never be transmitted to or stored on the server. The server stores only public keys or JWKS URLs. Clients should store private keys securely — in a keychain, encrypted file, or memory-only.

JWT lifetime

Agent JWTs should expire within 60 seconds. Short lifetimes limit misuse even without proof of possession. There are no refresh tokens — the client signs a new JWT for every request.

Replay protection

Servers must reject duplicate jti values within the JWT's lifetime window. Every JWT includes a unique jti claim, and the server tracks seen values to prevent replay attacks.

Proof of possession

The base protocol does not require proof of possession — short-lived JWTs over TLS are sufficient for many applications. For sensitive operations, servers should support a standard proof-of-possession profile:

• DPoP — the client sends a separate DPoP proof JWT on each request
• mTLS — the client authenticates with a TLS client certificate

This keeps the baseline simple while giving higher-assurance deployments a standards-aligned path.

Approval security

User approval is the primary trust boundary. First-time host approval is the highest-risk moment — the server knows nothing about the host beyond a self-signed keypair.

• Servers should present requested capabilities clearly and warn if the host requests unusually broad access
• Capability escalation deserves the same scrutiny — servers should not auto-approve high-risk capabilities even for linked hosts
• Approval pages should require fresh authentication — a long-lived session cookie alone is not sufficient

Self-authorization attacks

Agents often run with access to the user's browser or session (via browser tools, MCP, automation frameworks). This creates a unique threat: an agent could navigate to the device authorization URL and approve its own registration without the user being physically present.

Mitigations, from least to most restrictive:

• Fresh authentication — require the user to have authenticated within a short window (e.g. 5 minutes)
• Biometric passkeys (WebAuthn) — proves a human is physically present
• Hardware security keys — physical interaction required
• TOTP/OTP from a separate device — ensures the approver has a second factor the agent can't access

Discovery security

Discovery of arbitrary URLs is a prompt injection vector. A malicious prompt can trick an agent into calling discover_provider with a fake URL, which returns a fake configuration pointing registration at an attacker's endpoint.

Mitigations:

• Registry-first discovery — clients should resolve new services through a trusted registry rather than arbitrary URLs
• User confirmation — if discover_provider is called with a direct URL, require user confirmation before fetching
• Allowlists — clients may maintain an allowlist of trusted service URLs
• TLS verification — clients must verify TLS certificates when fetching discovery endpoints

Key compromise

If an agent's private key is leaked, anyone holding it can impersonate that agent. Unlike bearer tokens, the private key never traverses the wire — it can only leak from the client's local storage.

Mitigations:

• Host-authorized key rotation — use POST /agent/rotate-key with a Host JWT to immediately invalidate the compromised key
• Short TTL — agents with short session TTL values auto-expire, limiting the window of compromise
• Immediate revocation — revoke the agent if compromise is detected
• Secure storage — store private keys securely (keychain, encrypted file, memory-only)

Revocation cascade

Revoking a host must cascade to all agents under it. This ensures that if a host is compromised, all agents running under it are immediately terminated.

Rate limiting

Servers must implement rate limiting. Agents can generate high request volumes — both legitimately and due to bugs or compromised keys. Rate limits should apply at multiple levels:

• Per-agent — limits individual agent request rates
• Per-host — limits total requests from all agents under a host
• Per-capability — limits execution of specific high-cost capabilities
• Global — overall server protection

URL fetch protection

Both servers and clients fetch external URLs as part of the protocol. Servers fetching JWKS URLs must apply:

• IP filtering — block private, loopback, and link-local ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16, ::1, fc00::/7). Resolve DNS before connecting and check the resolved IP — not just the hostname.
• DNS rebinding protection — pin the resolved IP for the request duration
• HTTPS only — reject http:// URLs
• Redirect limits — follow at most 3 redirects, validating each target against IP filtering rules
• Response size limits — cap response bodies (e.g. 1 MB for JWKS)
• Timeouts — enforce connect and read timeouts (e.g. 5 seconds each)

Clients fetching discovery endpoints, OpenAPI specs, or server JWKS should apply: HTTPS only, response size limits, timeouts, and redirect limits.

Clients must also validate URLs returned by the server — status_url (async polling), verification_uri (device authorization), and notification_url (real-time approval). A malicious server could return URLs that point to the client's local network or serve phishing pages. For status_url, the URL must share the same origin as the server's issuer URL.

JWKS content validation

After fetching a JWKS document, servers and clients must validate its contents:

• The response must be valid JSON conforming to RFC 7517 §5
• The keys array must contain at least one key
• Only asymmetric key types (RSA, EC, OKP) are permitted — reject symmetric keys (kty: "oct")
• Servers should limit the number of keys (e.g. 20) to prevent signature-verification abuse
• Cache JWKS responses with a maximum duration (e.g. 24 hours) and minimum refresh interval (e.g. 5 minutes)

Discovery downgrade attacks

The algorithms field in discovery tells clients which key types the server accepts. If an attacker modifies the discovery document in transit (via a compromised cache or DNS hijack), they could force clients to register with weaker algorithms. TLS is the primary defense. Clients should reject unexpected algorithm downgrades — if a server previously supported Ed25519 and a subsequent discovery fetch no longer lists it, the client should warn the user or refuse to proceed.

Constraint enforcement atomicity

Constraints are validated when the server processes the execution request, but the underlying data may change between validation and execution (a TOCTOU gap). Servers should validate constraints and execute atomically where possible (e.g. within a database transaction), re-validate at each step for multi-step operations, and ensure constraint-validated operations are idempotent.

Cross-server capability confusion

Each agent JWT includes an aud claim set to the server's URL. Servers must reject JWTs where aud doesn't match. Clients must set aud to the specific server's URL for each request and must never reuse a signed JWT across servers — even if two servers share a capability name.

Implementation guidance

Caching

• Agent and host data — cache status, public keys, and granted capabilities in memory with a short TTL (5–30 seconds). Revocation propagation is delayed by at most the cache TTL. Use shorter TTLs or event-driven invalidation for stricter revocation requirements.
• Discovery — cache locally and re-fetch no more than once per hour. Force a re-fetch on unexpected 404 or 410. Maximum cache lifetime of 24 hours.
• Capabilities — cache list and describe responses. A max-age of 300 (five minutes) is recommended. Invalidate on capability_not_found errors during execution. Cache must be keyed by both endpoint URL and requesting identity.
• JWKS — cache responses and refresh periodically (every 5 minutes or on kid miss). Handle unavailability gracefully — use previously cached keys.
• Replay detection — the jti cache does not need persistence. An in-memory cache or bloom filter with a 90-second TTL is sufficient.

Key storage

Clients should store private keys securely:

• Desktop/server — OS keychain, encrypted file, or hardware security module
• Memory-only — acceptable for ephemeral agents where key loss is tolerable
• Environment variables — common but less secure (visible to process inspection tools)

Pending agent cleanup

Servers should periodically clean up agents that remain in pending state beyond a server-defined threshold (e.g. 24 hours, 7 days). Cleaned-up pending agents are deleted, not revoked — they never became active. Hosts in pending state should be cleaned up similarly.

User-facing terminology

The protocol uses "host" to describe the client's persistent identity. In user-facing surfaces — dashboards, approval screens, settings — servers should present hosts using familiar labels such as "Connected Apps," "Applications," or "Authorized Apps."

Display-text safety

Several protocol fields shown on approval screens are attacker-controlled: name, reason, host_name, and binding_message. Servers must sanitize these fields before rendering — strip HTML, limit length, and escape special characters. Servers should warn users when display names resemble well-known brands (homoglyph detection) and must not render these fields as trusted content.