NawGate

Inspiration

We started NawGate after thinking about a simple problem: when a user gives an AI agent a task, how much of the user’s access should the agent receive?

Giving an agent the same permissions as its owner is convenient, but it is also risky. An agent might access the wrong file, perform an action for the wrong user, or repeat a sensitive action accidentally. Prompt instructions alone are not enough because the model should not be responsible for deciding its own permissions.

This led us to focus on the Bouncer track. We wanted to build middleware that checks an agent’s identity and permissions in the backend before allowing it to access a protected resource or perform a sensitive action.

What NawGate does

NawGate is a delegated-access middleware for AI agents. It separates three identities:

The human using the platform
The Agent created by that human
The temporary Run performing the current task

An Agent does not automatically inherit all of its owner’s permissions. Each Run receives a short-lived credential, and protected actions must pass through NawGate’s RuntimeGateway.

The gateway can return three decisions:

ALLOW
DENY
REQUIRE_APPROVAL

For example, User A’s Agent can read User A’s project, but it cannot read User B’s project. A higher-risk action, such as a production deployment, pauses and waits for approval. If approved, NawGate creates a short-lived, one-use capability for that exact action. Reusing the capability or changing its action, resource, Run, or destination causes the request to be denied.

Owners can also revoke a Run or an Agent’s Team Grant. NawGate checks authorization again immediately before a protected side effect, so an action that was initially allowed can still be stopped if its authority is revoked while it is waiting.

Team and DAG coordination

We also added support for teams of Agents. A Team task can be divided into a directed acyclic graph, or DAG, where each node represents work assigned to an Agent and each edge represents a dependency.

Tasks without unfinished dependencies can run in parallel. Their sanitized results and created-file references are shared through a blackboard so that later Agents can build on earlier work.

The model may suggest a DAG, but the backend validates it before execution. If the proposed graph is invalid, NawGate uses a deterministic fallback plan. The model can help coordinate work, but it cannot grant permissions or approve protected actions.

Team coordination also respects Agent ownership. Adding an Agent to a Team does not allow another user to take control of it or bypass cross-user isolation.

How we built it

We built NawGate on top of an existing Agent Launchpad. The original platform already supported Agent creation, a browser Playground, persistent workspaces, and multi-turn sessions. One of our main goals was to add middleware without breaking these existing features.

The frontend uses React and TypeScript, while the backend uses Fastify, Zod, and TypeScript. The proof of concept stores its state using the existing JSON store.

Codex CLI is currently used as the Agent Runtime. It can connect to either Volcengine Ark or an OpenAI-compatible Responses API for model inference. Codex is the current Runtime adapter, while NawGate is the authorization middleware around protected actions.

We kept policy decisions and enforcement separate. PolicyEngine decides whether an action should be allowed, denied, or approved. RuntimeGateway performs the final checks and executes the protected side effect.

The Agent Runtime uses agentctl to request registered actions over HTTP. The backend resolves the Human, Agent, Run, Team, grant, and resource information from trusted server state. It does not trust identity fields supplied by the model or frontend.

Challenges we faced

One challenge was handling approval safely. We could not allow approval to override every denial. For example, approving a request should not allow an Agent to access another user’s resource or use an expired credential. We therefore allow approval to satisfy only a valid REQUIRE_APPROVAL decision.

Replay protection was another challenge. We needed to ensure that an approved action could execute once but not twice. The capability is bound to the exact Run, action, resource, payload, and destination. It is consumed atomically when the action executes.

Revocation created a timing problem. An action might pass its first policy check and then lose permission before execution. To handle this, NawGate performs a final authorization check immediately before the side effect.

We also had to keep protected files and credentials outside the Agent workspace. If an Agent could read them directly, it could bypass the gateway completely. Protected resources are therefore controlled by the backend, and only redacted results are returned.

Local and container execution introduced additional setup problems, especially Node.js versions, container networking, mounted directories, and RuntimeGateway addresses. We created a local POC startup script that detects Docker, Colima, or Podman and configures the required paths and gateway address.

Evidence and safety

NawGate produces a Delegation Receipt for protected actions. The receipt explains the policy decision, risk level, approval state, authority used, and whether a side effect occurred.

Before prompts, outputs, audit explanations, or flight recordings are stored, a deterministic DLP service masks common secrets and personal information. Runtime credentials and protected payloads are not included in the evidence shown to users.

Audit events are linked using SHA-256 hashes. If the chain is modified, NawGate enters an integrity quarantine. Existing evidence remains readable, but new protected actions and audit writes are blocked.

The Flight Data Recorder stores a sanitized record of each completed Playground Run. The owner can replay the Run’s prompt, output, timing, token usage, and related policy events without rerunning the original side effects.

What we learned

The main lesson from this project was that Agent authorization should not depend on the Agent behaving correctly. A secure design needs backend-owned identity, limited credentials, clear enforcement points, revocation, and audit evidence.

We also learned that orchestration and authorization are different problems. A DAG can decide which Agent should work next, but it should not decide whether that Agent is allowed to perform a protected action.

Finally, we learned that security evidence must also be protected. Logs are useful for debugging and demonstrations, but they can create another data leak if credentials, prompts, or protected content are stored without redaction.

Current result

NawGate can demonstrate normal access, cross-user denial, human approval, one-use capability execution, replay denial, JIT access, grant revocation, Run revocation, final recheck after revocation, Team DAG execution, DLP masking, audit integrity, and sanitized replay.

The repository includes installation instructions, architecture diagrams, a complete demo guide, automated tests, and documented limitations. In our latest verification, 168 tests passed and both the frontend and backend builds completed successfully.

NawGate is still a proof of concept. It uses a single-process JSON store and does not claim hardened multi-tenant container isolation or interception of every shell, filesystem, or network action. Future work could include a production database, distributed task coordination, stronger Runtime isolation, and integration with real external services.

Architecture Design

Github Link