Inspiration

Autonomous AI agents are increasingly able to interact with powerful tools such as databases, email systems, APIs, and internal services. That creates a security problem: an agent may consume untrusted content and be manipulated into proposing actions that its user never intended.

A lot of attention is placed on detecting prompt injection itself. I wanted to explore a different question:

What if we assume the agent can be manipulated, but refuse to automatically trust the actions it proposes?

That idea became AgentGate — a zero-trust runtime security gateway that sits between an autonomous agent and its tools.

What it does

AgentGate intercepts proposed tool calls before they execute and evaluates them against deterministic, least-privilege security policies.

Every request can result in one of three decisions:

  • ALLOW — the action is permitted and may execute.
  • BLOCK — the action violates security policy and cannot execute.
  • REQUIRE_APPROVAL — the action may be legitimate, but requires human authorization before execution.

AgentGate also generates an explainable risk score, severity level, triggered policies, and an audit event for each decision.

The key idea is that risk scoring explains a request, while policy authorizes it. Authorization is not simply based on whether a numerical score crosses a threshold.

Attack simulation

The demo includes three deterministic scenarios.

Normal support workflow

A customer-support agent looks up an order and sends its tracking information. Both actions fall within the agent's permissions, so AgentGate allows the requests and the simulated tools execute successfully.

Prompt injection attack

The agent encounters an untrusted support document containing malicious instructions to ignore its previous instructions, retrieve 5,000 sensitive customer records, and send them to an external destination.

The simulated agent is successfully manipulated and proposes the dangerous database request.

AgentGate evaluates the proposed action and triggers policies for:

  • bulk sensitive-data export
  • external sensitive-data transfer

The request receives a risk score of 80/100 (CRITICAL) and is BLOCKED before the database tool executes.

This demonstrates the core idea behind AgentGate: it does not need to perfectly identify every possible prompt injection. Even if an agent is manipulated, its ability to affect external systems can still be independently constrained at the tool boundary.

Human approval

The third scenario proposes deleting an order. The action is allowlisted but destructive.

It receives a relatively low risk score of 25/100 (LOW), yet AgentGate still returns REQUIRE_APPROVAL and prevents automatic execution.

This demonstrates the separation between explainable risk scoring and deterministic authorization policy.

How I built it

AgentGate consists of a React + TypeScript security dashboard and a FastAPI/Python backend.

The backend implements:

  • typed tool requests and agent permissions
  • deterministic policy evaluation
  • explainable risk scoring
  • decision precedence (BLOCK > REQUIRE_APPROVAL > ALLOW)
  • security audit events
  • scenario simulation through the same guarded execution path used by evaluated tool calls
  • REST APIs for evaluations, scenarios, health checks, and audit events

The React dashboard communicates with the live API and visualizes decisions, risk levels, triggered policies, execution status, and the audit trail.

The application is packaged as a multi-stage Docker image, with the compiled React frontend and FastAPI API served from a single container.

I deployed AgentGate to Azure Container Apps, with images stored in a private Azure Container Registry. The running application pulls its container image using an Azure managed identity and scoped RBAC permissions.

I also built a GitHub Actions CI/CD pipeline. Every push to main runs the backend tests, frontend tests, production frontend build, and Docker build. After CI succeeds, a separate deployment workflow authenticates to Azure using OIDC rather than a permanent client secret, builds and pushes an image tagged with the exact tested Git commit, deploys it to Azure Container Apps, and verifies the live health endpoint.

Challenges I faced

One of the biggest design challenges was separating risk from authorization. It would have been easy to implement a simple system such as "block anything above a risk score of 50", but that would make the score itself the security boundary. Instead, AgentGate uses deterministic policies for authorization and treats the risk score as an explainability signal.

Cloud deployment also produced several practical challenges. My Azure student subscription did not allow Azure Container Registry Tasks, so I adapted the deployment process to build the production image through Docker and push it directly to the registry.

I also encountered regional Azure resource constraints and identity limitations while configuring Container Apps. This led me to use separate managed identities with least-privilege roles for runtime image pulling and GitHub deployment.

Finally, configuring passwordless GitHub-to-Azure deployment required correctly setting up OIDC federation and repository identity claims. Working through these issues gave me much more practical experience with cloud identity, RBAC, containers, and CI/CD.

What I learned

This project changed how I think about AI-agent security. Instead of relying entirely on determining whether an agent's reasoning or input is trustworthy, important actions can be placed behind an independent authorization boundary.

I also learned a lot about building and deploying a complete system: connecting a React frontend to a FastAPI service, designing policy-driven security logic, containerizing a full-stack application, deploying private images to Azure, configuring managed identities and RBAC, and implementing passwordless CI/CD with GitHub Actions and OIDC.

What's next

AgentGate is currently a hackathon prototype using deterministic simulated agents and tools; it does not interact with real customer databases, email systems, or an LLM.

Future work could include:

  • adapters for real agent frameworks and tool protocols
  • persistent audit storage
  • a complete human approval workflow
  • policy-as-code configuration
  • richer identity and contextual authorization
  • cryptographic audit-event integrity
  • multi-tenant policy isolation

The longer-term goal is to make AgentGate a reusable security layer that allows autonomous agents to remain useful without implicitly trusting every action they propose.

Built With

Share this project:

Updates

Submission history