Remote-Brokered Back Channel HITL: A Secretless Authorization Foundation for AI Agents

The Gap

As MCP and agentic workflows proliferate, a new requirement has become tangible: AI agents performing high-privilege operations only after explicit user approval. Writing to production databases, processing payments, making write calls to external APIs — leaving these to LLM judgment alone is too risky, but pre-composing every request defeats the purpose of using an agent in the first place. The natural landing point is a pattern where the agent proposes an operation and a human asynchronously approves it.

Structurally, this pattern is clear. The client (the agent) sends an approval request to the authorization server over a back channel, the authorization server notifies a human, and once approval comes back through a separate channel (a mobile app, for example), an access token is issued. Several standards specify similar back channel authentication flows, but none of them fit the AI agent use case as-is.

The root cause boils down to one thing: agent authentication itself depends on a sharable secret. This is a structural weakness.

What This Proposal Aims to Achieve

The design presented here is intended to satisfy three goals simultaneously:

1. Run AI agents in a secretless environment: Place no persistent secrets and no laterally-usable keys anywhere within the agent’s visible scope (process memory, filesystem, environment variables). The agent’s only identity is a short-lived SVID derived from its execution context.
2. Enable external service integration: Provide a path for agents to acquire access to risky external systems — production DBs, payment systems, external APIs — as needed. Secretlessness and external integration capability are not in conflict.
3. Make Human-in-the-Loop authorization designable: Embed an operationally viable mechanism in which permissions for irreversible operations are issued only after explicit human approval. This includes the flexibility to align approval granularity with operational risk.

The key to satisfying all three lies in combining secret-fileless, attestation-bound identity (made possible by SPIFFE) with remotely-isolated token brokers. In short, this is a Remote-Brokered Back Channel HITL. The authentication mechanism at its core is what this article calls Secretless Back Channel Authentication. The rest of this article walks through why existing patterns fall short and how this design closes the gap.

Why Existing Patterns Aren’t Enough

Recall the typical back channel authentication flow. The client (agent) authenticates itself to the authorization server’s back channel endpoint using client_id + client_secret (or an assertion based on a pre-registered key), and then submits an approval request. The authorization server notifies a human, and on approval, issues an access token.

Now consider the case where “the client” is an AI agent:

• Hundreds to thousands of agent instances may run in parallel
• Each instance starts and terminates frequently as a container
• Some run in the user’s local environment, others on managed services
• Even instances derived from the same codebase and image have wildly different execution contexts

Distributing a client_secret across this world is effectively distributing a shared secret. When that secret leaks, there is no way to trace which instance leaked it. Audit logs record client_id, but that only tells you "this application made the request." Which execution context, which process — that remains forever unknown.

Switching to assertion-based authentication with a pre-registered key changes nothing fundamentally. How to distribute the key, where to store it, how to revoke it on leak — every concern still reduces to the secret distribution problem.

What an agent-era authorization foundation needs is client authentication that is cryptographically identifiable per instance.

SPIFFE-bound Back Channel Authentication

SPIFFE was designed precisely for this problem. Workloads receive an SVID at startup through attestation (a chain of evidence rooted in the node and the workload itself). The SPIFFE ID bound to that SVID is derived from the execution context itself, not from a distributed secret.

Consider performing the back channel authentication request over SVID-based mTLS plus a JWT-SVID assertion. Concretely:

• Transport is mTLS using X.509-SVIDs
• The client assertion carries a JWT-SVID
• The authorization server verifies the JWT-SVID against the trust bundle and treats the SPIFFE ID as the client identifier
• Access tokens issued after approval are bound to the originating SPIFFE ID

While this can be implemented as an extension of OAuth 2.0 client authentication, the emphasis here is not on conformance to any particular specification. The point is the design principle: decouple the client authentication that runs over the back channel from secret distribution entirely.

What matters is the fact that SPIFFE IDs are bound to attestation. An ID like spiffe://example.org/agent/db-writer/instance-xyz is only ever issued to a process that passed through a specific workload startup path on a specific node. Even if it leaks, it cannot be used on another node. The secret distribution problem simply disappears.

As introduced at the top, this is what I call Secretless Back Channel Authentication. It is the component of the broader Remote-Brokered Back Channel HITL form that handles authentication between the agent and the token broker.

What This Unlocks

Once Secretless Back Channel Authentication is in place, several properties come along automatically.

Per-instance accountability: Audit logs record SPIFFE IDs pointing to specific agent instances, not application-level identifiers. Not just “which code requested this” but “from which execution context did the request originate” — with cryptographic backing.

The absence of secret rotation: SVIDs are short-lived (minutes to hours) and auto-renewed. The traditional pains of client_secret rotation operations and emergency rotations on suspected compromise simply do not exist at the design level.

Stronger approval context: When a human sees an approval screen, they no longer see “request from application X.” They see “request from instance B running on node A (attestation trail: built through a specific build pipeline, currently running on the production cluster).” The quality of approval judgment shifts accordingly.

Surveying the agent identity solutions offered by major cloud vendors and IdPs, there are efforts to standardize token exchange and federation, but the gap of binding agent authentication and the human approval layer through cryptographic identity remains open. Back channel authentication built on SPIFFE fits precisely into that gap.

Deployment Pattern: Permission-Scoped Token Brokers

When implementing Secretless Back Channel Authentication, there is no need to build the authorization server as a monolith. In fact, deploying independent serverless token brokers per permission type is a natural fit.

What’s important here is that not every operation an agent performs needs to be subject to human approval. LLM inference, internal API reads, code execution inside a sandbox — operations that are reversible or whose blast radius is contained can be completed using only the regular workload identity. Production DB writes, payment confirmations, irreversible outbound calls to external systems — carving out only these irreversible external operations for selective pre-approval is the heart of this design. Pay the cost of human approval only where the risk warrants it; leave everything else to the agent’s autonomy. The principle is to align approval granularity with risk granularity.

Each broker carries its own SPIFFE ID and is restricted to issuing only the scopes it owns. A “production DB write approval broker,” a “payment execution approval broker,” an “external API outbound approval broker” — each deployed as a separate workload. Tokens for low-risk operations bypass the approval flow entirely and flow through ordinary SVID-based access.

Agent (SVID: spiffe://.../agent/x)
  │
  │ back channel req (JWT-SVID assertion + mTLS)
  ▼
Broker: db-write (SVID: spiffe://.../broker/db-write)
  │
  │ human approval channel (template fixed per broker)
  ▼
human approval
  │
  ▼
token scoped to db:write only

The essence of this separation is the design principle: place no secrets whatsoever within the agent’s visible scope.

The brokers that issue permissions are remotely isolated. The agent holds nothing beyond its own SVID — short-lived, attestation-derived, unusable on any other node. Production DB credentials, payment API keys, tokens for external systems — all of these live on the broker side, and reach the agent only as scope-restricted, short-lived tokens after human approval.

This property gives the agent’s runtime environment a powerful kind of resilience. Even if an agent process is compromised and the attacker gains root inside the container, the most they can extract is an SVID valid for a few minutes and any scope-restricted token issued for an in-flight request. Persistent secrets, laterally-usable keys, credentials capable of issuing other permissions — none of these exist anywhere within the agent’s visible scope. Even if the LLM itself follows attacker instructions through prompt injection, the result is the same: to obtain a new permission, the attacker must also submit a legitimate back channel authentication request to a broker and wait for human approval.

Separating brokers per permission type is the operational mechanism that implements this principle. If you collapse all permissions into a single general-purpose authorization server, even with SVID-based authentication, a single authorization endpoint becomes capable of issuing many scope types, and the blast radius of a broker-side compromise expands accordingly. By splitting them into independent serverless workloads per permission, you minimize the type and quantity of secrets each broker handles.

A world in which both the agent and the broker hold nothing beyond the minimum permissions and short-lived credentials they need — this is where Remote-Brokered Back Channel HITL lands. Each per-permission broker can be viewed as a micro-Authorization Server, and SPIFFE gives all of them a common identity system, providing the foundation for mutual authentication between brokers and between brokers and agents. The per-instance accountability mentioned earlier extends, in this design, to per-permission accountability. Both the “who” of the agent and the “what” of the permission are spoken in the language of cryptographic identifiers.

Client-Side: Container Isolation and Hardware-Key Authentication

One last point on the client side. Clients using an AI agent can isolate the agent itself inside a container and have it request SVIDs through the Workload API socket. The agent process has no direct access to the host environment; the credentials it needs arrive over the socket as nothing more than short-lived SVIDs. Even if the agent goes rogue, the most it can carry out is an SVID with a few minutes of validity. The underlying private key cannot be extracted.

At this point, anchoring the node attestation root in hardware lets you push the trust root of the entire setup down to a physical device. I have published a PoC on GitHub that uses hardware keys such as YubiKey via PKCS#11 as the basis of node attestation on Windows and macOS (spire-plugin-node-attestor-x509pop-pkcs11). My hope is that it serves as a foundation for building a zero trust base for the agent era, starting from the individual developer’s endpoint.

This, I believe, is one shape that HITL authorization infrastructure can take in the AI agent era — a Remote-Brokered Back Channel HITL.