In-depth analysis · About 4 min read
An AWS–Keyfactor reference design binds agent calls to signed user delegation
X.509 certificates, request signatures, scoped tokens and revocation checks establish identity; they do not validate the business correctness of a database action.
- Published here
- Source published
- Source checked
AWS and Keyfactor’s October 20 walkthrough describes a three-layer identity chain from user login through inter-agent calls to an MCP tool server. Its database example uses Amazon Bedrock, Strands, Keycloak and EJBCA Enterprise. The useful distinction is between an agent presenting a credential and proving that a specific request is signed by a specifically authorized key holder.
Listen to the news
Read this article aloud or keep listening to the news.
Preparing the reader…
Device voice
Speech is handled by your browser or device. AISubHub does not send the text to an audio API. Voice availability and playback with a locked screen vary by device.
Resuming may repeat a short phrase.
At a glance
- The example signs request envelopes, carries user-signed delegation and exchanges a full-session token for an audience-scoped token; the final server checks their identities agree.
- Envelope freshness defaults to 60 seconds, nonces are 128-bit random values, and the in-memory replay cache retains them for twice the freshness window.
Separate the user’s authority from the agent’s key
The application authenticates the user and obtains a narrower token through RFC 8693 token exchange. The intended audience is the protected MCP service, rather than every service reachable by the original session token. It locally generates RSA keys of at least 2048 bits and sends only a certificate signing request to EJBCA. The returned certificate and private key are packaged for storage in Secrets Manager; the private key is not sent to the certificate authority. The user signs a delegation listing the SHA-256 fingerprints of authorized agent certificates and an expiry. Agents therefore carry an authorization assertion rather than receiving the user’s private key or full-session token. Each agent has its own key.
A certificate alone is not proof of a fresh request
The caller signs the tool name, arguments, timestamp and nonce with RSA-PSS-SHA256. The receiver verifies signature, freshness, nonce uniqueness, trusted CA chain, allowed caller role and OCSP status. The default 60-second window and replay cache serve different purposes: an old request expires, while a recently captured valid request is rejected if its nonce was already used. A retry must use a new envelope and nonce. This does not itself establish that a retried business operation runs only once. The example cache is thread-safe but in memory; the guide names a shared ElastiCache-backed design as an extension for distributed deployments. Replicas must not each forget a nonce that another replica already accepted.
The tool server joins the identity evidence
Before a database operation, the reference server checks that the token is active and has the expected audience, verifies the signed envelope, validates the user’s delegation and its authorized certificate fingerprint, and cross-checks token username, delegation subject and agent certificate identity. The role map permits the orchestrator to call the database or email sub-agent, without granting arbitrary sideways or upward calls. AISubHub analysis: these checks answer who requested an operation and on whose authority. They still require appropriate database permissions and operation-level policy. The guide’s token-exchange example and validation shorthand use different audience strings; implementers must align actual issuer and verifier settings rather than copy fragments as a working configuration.
Revocation creates an availability dependency
The design denies requests when OCSP is unreachable or another validation fails. Logout revokes the user and three agent certificates, removes stored secrets and ends the identity-provider session. Revoking the user certificate invalidates delegation at subsequent checks; the guide describes this as immediate propagation through per-request OCSP. In practice this remains a property to verify under the configured responders, caches, failures and clocks, not a measured universal latency bound. The example certificate profile has seven-day validity. High-availability responders, distributed replay state, key rotation and audit retention therefore belong in acceptance work. Guardrails and bounded tool access can complement the identity chain, but neither signed requests nor content filtering proves the correctness of every generated operation.
Why it matters
AISubHub analysis: identity and delegation should be enforced at the tool boundary, rather than left to model instructions. A valid identity chain still cannot prove that generated SQL is sensible or that a requested operation meets business policy.
Limits and availability
This is a reference architecture, not an independently tested security certification. We did not run it. Prerequisites include Keycloak 26.2 or later and EJBCA Enterprise with OCSP; deployment, licensing and service costs are not quantified here.
Sources and evidence
Source published: · Source checked:
AI-assisted editorial articles checked against linked primary sources. Vendor claims are attributed; inclusion is not endorsement.