Why Excalibur exists & how it works¶
This page explains the secret-residency problem, the broker topology, the four principal kinds, and the three-tier hardware-rooted trust root.
The problem¶
Modern services do not have a "secret leak" problem. They have a secret residency problem.
Every credential a workload uses — database password, payment-API key, OAuth refresh token, signing key — is loaded into the same process that runs the application code. From that moment:
- Every line of application code can read it.
- Every transitive dependency the build pulled in can read it.
- Every observability agent that injects into the process can read it.
- Every core dump, every crash report, every memory profiler can read it.
A modern Node, Python, or Go service ships with hundreds of unreviewed packages from public registries. Any one of them runs inside the workload process. Any one of them can read the credential the moment the workload makes its next outbound call.
Rotation cadence shortens the exposure window. It does not change where the credential resides. As long as the workload is the residency point, the workload is the blast radius — and the blast radius is everything that touched the build.
The shape of the answer¶
A mediator sits on the network path between the workload and the upstream provider.
- The real credential is held only in the mediator, in an encrypted store the workload has no read path to.
- The workload only ever holds a label (a placeholder, e.g.
XCALIBUR_STRIPE_SECRET_KEY). The label is a public identifier; it is safe to commit, safe to screenshot, safe to log. - On every outbound call, the mediator authorises the substitution against the identity it has for this caller, performs whatever upstream authentication the route requires (bearer header, cookie, JWT, DPoP proof, mTLS handshake, AWS SigV4 signature, …), and relays the response.
- The upstream sees a correctly authenticated client. It cannot tell the mediator from the workload.
- The workload never sees the real credential — not at startup, not at runtime, not in a stack trace.
The mediator is transparent at the protocol level: the workload
sends the same plain HTTP it always sent, configured with two
environment variables (HTTP_PROXY, HTTPS_PROXY). No SDK, no
sidecar, no in-process agent.
Identity — who is asking?¶
A credential is only as safe as the identity check that gates it. Excalibur normalises every caller into a single principal model with four kinds, so authorisation rules read the same regardless of where the call came in from.
| Principal kind | Onboarding path | Typical workload |
|---|---|---|
user_session |
SSH session through Excalibur's SSH gateway | Operator on a jump host, interactive dev shell |
service |
Long-lived service credential bound to a source CIDR | Build runners, batch jobs, on-prem services |
workload |
Per-call platform attestation (Kubernetes, OIDC, cloud) | Pods, GitHub Actions jobs, GCP / AWS / Azure workloads |
developer_device |
Overlay-network peer identity (NetBird / WireGuard) | Roaming engineers on managed laptops |
The right path for any given workload is whichever one its platform already provides. No path requires installing Excalibur software on the workload.
See Onboarding a workload for walkthroughs of each path.
The trust root — why the broker is not just a new thing to trust¶
The most reasonable objection to a credential broker is "now the broker is a single point of compromise."
Excalibur's answer is three independent properties, none of which depend on the broker operator's word. Each is rooted in something verifiable outside the broker itself.
Workload identity is not a shared secret¶
The workload presents a fresh attestation document, minted per request by the platform it runs on, bound to its measured state. There is nothing static for an attacker to lift off disk and replay elsewhere.
Supported platform-issued identity sources:
- Cloud metadata services (AWS IMDSv2, GCP, Azure)
- Kubernetes projected service-account tokens (verified against the cluster's own JWKS)
- SPIFFE / SPIRE workload identity
- Host TPM quote
- GitHub Actions OIDC (verified against the Actions JWKS)
- Generic OIDC issuers configured by the operator
Broker integrity is verified, not vouched for¶
The broker process can be deployed inside a confidential virtual machine (AMD SEV-SNP, Intel TDX). A remote attestation quote, signed by the silicon, proves to the workload — and to your auditor — that the binary executing on this host is the binary the vendor signed, on a known firmware. You do not have to trust the cloud operator, the host kernel, or the broker administrator.
Key material is sealed in silicon¶
The credential-encryption key is held in an HSM (PKCS#11) or the host TPM. The broker asks the silicon to sign or unwrap; the key bytes never enter user space, never page to disk, never appear in a core dump. Compromise the broker host, and what you read off the disk is ciphertext.
| Layer | Independent guarantee |
|---|---|
| Workload | Hardware-rooted identity (TPM quote, cloud IMDS, K8s SA, SPIFFE) |
| Broker | Hardware-attested integrity (SEV-SNP, TDX measured boot) |
| Key material | Hardware-sealed escrow (HSM PKCS#11, TPM 2.0 sealed key, cloud KMS) |
These compose. An attacker who breaks one tier still has to break the other two.
The universal pipeline¶
Excalibur runs the same five steps in the same order on every outbound request — payment API, cloud storage upload, git push, webhook delivery, package-registry pull, anything. There are no fast paths, no protocol shortcuts, no debug branches. That uniformity is the reason the audit trail is worth anything.
| # | Step | What happens |
|---|---|---|
| 1 | Classify destination | Resolve target host against the allow-list bound to this caller. Apply egress policy and namespace policy. |
| 2 | Identify caller | Resolve the canonical principal — service credential, attestation document, SSH session, overlay peer. |
| 3 | Substitute credential | Swap each placeholder in the request for the real value, fetched from the encrypted escrow store. |
| 4 | Sign | Apply whatever upstream the destination protocol actually requires: bearer header, cookie, JWT, DPoP, mTLS, AWS SigV4, … |
| 5 | Record | Write a hash-chained audit entry before the connection opens. Every event hash includes the previous hash. |
If any step refuses, the request does not leave the broker. The default is deny. Unknown destinations, unknown callers, unknown placeholders, missing translation rules, expired attestations — all fail closed.
Three operating modes¶
Excalibur has three operating modes you can switch between at runtime:
| Mode | What happens |
|---|---|
| Discovery | Observe traffic, classify it, propose adapter rules. No request is modified. |
| Shadow | Adapters run against live traffic but their output is compared, not applied. Use this to gain confidence before flipping to enforcement. |
| Enforcement | Adapters mutate traffic, unknown HTTP flows fail closed, raw non-HTTP TCP is blocked. This is the production posture. |
The mode is persisted and visible in the header strip of every dashboard page so an operator always knows which posture is live.
Figure 1. The header strip on every dashboard page surfaces the current
mode (ENFORCEMENT here, in red).
What you get, in one paragraph¶
A workload that no longer holds the real credential. An operator who can rotate, revoke, or re-scope upstream access in one write, without coordinating with the workload. A platform team that can prove — to themselves, to the workload, and to the auditor — that the broker running in production is the binary the vendor signed, on a known firmware, with key material sealed in silicon the broker operator cannot read. A security team with a single audit channel for every machine-to-internet decision the organisation makes, hash-chained, write-protected against the caller, and tied to a verifiable identity.
That is what we mean by machine identity & credential mediation. The rest of this section shows you how to operate it.