Agent Trust Gateway

Login Page
Frontend Agent View
Create Agent
Agent Settings
Access and Audit Page (for testing scenarios)
Agent Pass
Agent Playground

Inspiration

As software developers, we have seen how quickly AI coding Agents are becoming part of everyday engineering workflows. However, most Agent demonstrations assume that every user, Agent, file, and tool exists within a single trusted environment.

That assumption does not reflect how real software teams operate. A Frontend developer should not automatically gain access to a Backend Agent’s workspace, conversation history, credentials, or private files. At the same time, completely preventing collaboration makes coding Agents much less useful.

We built Agent Trust Gateway to explore a safer middle ground: coding Agents can collaborate across engineering teams, but only through explicit, narrowly scoped, and auditable permissions.

Our goal was not simply to hide resources in the interface. We wanted to build a genuine backend security boundary that determines who can use an Agent, what that Agent can access, and whether a delegated task is still authorized at the moment of execution.

What it does

Agent Trust Gateway is identity and authorization middleware positioned between users, coding Agents, protected resources, and the Agent Runtime.

The demonstration contains three engineering identities:

Frontend
Backend
QA

Each identity owns its own Agents, workspace, and protected resources. Every sensitive operation is checked by the backend using the authenticated session and stored ownership information. The browser displays the result, but it never makes the authorization decision.

The middleware can deny:

A user attempting to invoke another user’s Agent
An Agent attempting to read another owner’s resource
Reads of protected files such as .env
Paths that escape the Agent’s approved workspace
Unsafe shell commands
Unapproved network requests
Actions attempted by a revoked Agent
Delegated tasks that have expired, changed, been revoked, or already been used

Every authorization decision produces persisted evidence containing the authenticated user, Agent, action, target, decision, reason code, and request identifier. This evidence is displayed in the Access and Audit interface so reviewers can see exactly what was attempted, what the backend decided, and why.

Agent Trust Pass

The project’s distinguishing capability is the Agent Trust Pass, a consent-based mechanism for delegating one exact task without sharing the underlying Agent.

For example, a Frontend Agent may discover that it requires a Backend capability to finish a feature. Instead of exposing the Backend Agent or granting the Frontend team permanent access, Agent Trust Gateway allows the Frontend user to request permission for a specific task.

The Backend owner can review the request, inspect the exact task and approved inputs, select one of their own Agents, and approve or reject it.

An approved Trust Pass is bound to:

One authenticated requester
One owner-selected Agent
One exact task
A digest of the approved prompt
A defined set of approved inputs
One permitted action
A short expiry period
One use

When the delegated Run begins, the backend validates the requester, selected Agent, ownership, prompt digest, approved inputs, expiry, revocation state, and unused status. Admission atomically consumes the Trust Pass so that concurrent or repeated requests cannot reuse it.

The requester receives only the approved final result—not access to the Agent’s workspace, settings, history, or unrelated files.

A Trust Pass can be rejected or revoked by the owner. It closes once it expires, has already been consumed, contains changed resources, or is presented with an altered task.

How we built it

We preserved the Starter Kit’s existing React interface, Fastify API, AgentService lifecycle, Playground, and Codex-based execution workflow. We then added the Trust Gateway around these components as an integrated security layer.

The implementation includes:

A React and TypeScript interface for authentication, Agent management, policy testing, consent-based delegation, and audit evidence
A Fastify backend that resolves authenticated identities through HttpOnly sessions
Demo identity support and an optional Supabase authentication and persistence adapter
An ownership gate for user-to-Agent and Agent-to-resource authorization
A workspace file policy for canonical path validation, traversal protection, secret-file blocking, and file-size limits
A Runtime Action Firewall that checks file, shell, and network actions before dispatch
A delegation service for requesting, approving, rejecting, revoking, expiring, and consuming Trust Passes
Atomic delegated-Run admission that consumes a Trust Pass and records the authorization decision before execution
A disposable Codex Runtime with approved-input projection, an isolated workspace, a separate Codex home, resource limits, and networking and credentials disabled by default
BytePlus ModelArk integration through a Responses-compatible API
Persisted ALLOW and DENY decisions that can be inspected through the frontend

For delegated execution, the Runtime receives only the approved task and projected inputs. It does not receive the owner’s complete workspace, Agent history, control-plane credentials, or unrelated resources.

The system also verifies Runtime cleanup and fails closed when authorization evidence cannot be persisted. If the audit path is unavailable, no protected action or Agent Run is allowed to proceed.

We added automated tests covering:

Human-to-Agent ownership mismatches
Agent-to-resource ownership mismatches
Protected secret files
Workspace traversal attempts
Unsafe shell commands
Network restrictions
Revoked Agents
Rejected and revoked Trust Passes
Expired passes
Delegation replay attempts
Altered prompts
Changed approved resources
Audit-storage failures
Disposable Runtime isolation and cleanup

The repository can be validated through npm run check, which performs type checking, automated testing, and production builds.

Challenges we ran into

The first challenge was separating a convincing interface demonstration from real security. Hiding an Agent or disabling a button in React is not authorization. We had to ensure that every protected operation was independently checked by the backend using server-derived identity and persisted ownership data.

The second challenge was making a one-use Trust Pass genuinely single-use. If pass consumption and Run creation occurred as separate operations, concurrent requests could potentially reuse the same permission. We addressed this by treating delegated admission as an atomic state transition.

File authorization was another difficult area. Paths had to be normalized before policy evaluation, while traversal attempts, protected filenames, oversized files, and symlink-related escapes had to remain denied. We also needed to record useful evidence without copying protected file contents into logs or audit records.

Runtime isolation required balancing usefulness with safety. A coding Agent needs enough access to complete an approved task, but it should not inherit the control plane’s credentials or gain access to unrelated workspaces. We used approved-input projection, an isolated Runtime home, restricted container settings, resource limits, and fail-closed cleanup behavior.

We also needed to preserve the Starter Kit’s existing lifecycle. The security middleware had to integrate with Agent creation, startup, invocation, revocation, and Run management without replacing the platform itself.

Finally, we wanted the middleware to be understandable during a short hackathon demonstration. We created interactive policy scenarios, consent workflows, reason codes, and an audit timeline so reviewers can immediately understand what happened at each trust boundary.

Accomplishments that we're proud of

As software developers, we are especially proud that our security controls operate as real backend middleware rather than UI-only restrictions.

We built an ownership boundary that prevents one user from accessing another user’s Agents, resources, workspaces, or history.
We created the Agent Trust Pass, enabling cross-team collaboration through an exact owner-approved task without exposing the underlying Agent.
Every Trust Pass is scoped, time-limited, revocable, and single-use.
The middleware validates the requester, owner-selected Agent, ownership, prompt digest, approved inputs, action, expiry, revocation state, and consumption state.
We implemented fail-closed authorization: if an authorization decision cannot be persisted as evidence, the Agent Run never starts.
We added pre-execution controls for protected files, unsafe shell commands, network access, and paths outside the approved workspace.
We execute delegated tasks inside disposable, isolated Runtime containers containing only approved inputs.
We made every ALLOW and DENY decision understandable through the frontend, including its reason code, requester, Agent, action, target, and request identifier.
We preserved the Starter Kit’s original Agent lifecycle while introducing the Trust Gateway as an integrated middleware layer.
We created a reproducible implementation backed by automated type checking, production builds, and 176 passing tests.

What began as a straightforward access-control feature became a deeper answer to an important question:

How can autonomous coding Agents collaborate across trust boundaries without requiring their owners to surrender control?

What we learned

The most important lesson was that Agent authorization requires more context than a traditional role check.

A safe authorization decision may depend on:

Who is making the request
Which Agent will perform the action
Who owns that Agent
Which action is being requested
Which resources have been approved
Whether the task has changed
Whether an approved input has changed
Whether the permission has expired
Whether the permission has been revoked
Whether the permission has already been used

We also learned that delegation does not have to mean sharing an Agent. It can instead mean authorizing one precise outcome while keeping the underlying Agent private.

Another important lesson was that authorization and execution cannot be treated as unrelated steps. A decision must still be valid when the Run is admitted, and one-use permissions must be consumed atomically to prevent replay or race conditions.

Most importantly, we learned that audit evidence is part of the security boundary. If the system cannot persist the authorization decision, it should fail closed instead of executing an unaudited action.

What's next for Agent Trust Gateway

The next step is to evolve the proof of concept into a production-ready trust layer for multi-team Agent deployments.

Future improvements could include:

Enterprise identity providers and organization-level role management
Distributed atomic storage for Trust Pass transitions
Short-lived Runtime and model-provider credentials
A trusted model-egress proxy
Cryptographically signed Trust Passes
Configurable policy templates for different engineering teams
Complete correlated traces across policy, model, tool, sandbox, and Runtime events
Stronger production container and multi-tenant isolation
Owner-defined approval policies and reusable delegation workflows
Integration with external security information and event management systems

Agent Trust Gateway demonstrates that coding Agents can collaborate across engineering boundaries without requiring teams to give up ownership, privacy, or control.