Inspiration: What happens when an AI agent has too much power?
AI is moving beyond answering questions. Agents can interact with APIs, retrieve private information, modify records, issue refunds, and trigger real-world workflows. This opens incredible possibilities—but it also creates a new security challenge.
An AI agent can be helpful, capable, and still make a dangerous decision.
A prompt injection hidden inside a message could attempt to manipulate an agent. An innocent-looking request could trigger an unauthorized action. And a system that blindly trusts an AI model to decide what is safe may fail precisely when security matters most.
That raised a question for us:
What if we could let AI remain intelligent and flexible while ensuring that its actions are controlled by a security layer that does not blindly trust it?
That question inspired Trapdoor Gateway.
Our goal was not to build another chatbot or simply tell an AI model to behave safely. We wanted to explore a more fundamental idea: AI should be able to propose an action, but it should never automatically receive the authority to execute it.
Our Solution: A Security Gateway Between AI and Action
Trapdoor Gateway is a runtime security layer designed to inspect and control AI agent tool calls before they execute.
Instead of allowing an AI agent to directly invoke sensitive tools, Trapdoor places a policy-enforcement boundary between the agent and the action.
Every request passes through a simple but powerful decision process:
ALLOW: The action satisfies the defined security policy and can proceed.
BLOCK: The action violates a security rule and must not execute.
REVIEW_REQUIRED: The action needs trusted human approval before execution.
For our prototype, we implemented a simulated customer-support environment with tools such as order lookup, refund requests, and reply drafting.
For example, a refund below the configured threshold can be permitted, while a refund above the threshold requires review. A user-supplied approval flag is not accepted as proof of authorization. Similarly, a prompt-injection attempt can be flagged rather than being allowed to trigger a sensitive action.
The key principle is simple:
The model can recommend. The policy decides. The gateway enforces.
This separation is central to Trapdoor. Security decisions should not depend solely on whether an AI model says an action is safe.
How We Built It
We built Trapdoor as a working prototype using Python, FastAPI, Pydantic, and a web-based frontend.
The backend provides the gateway API, validates incoming requests, evaluates policy rules, and returns structured execution decisions. The prototype also includes an audit endpoint so decisions can be inspected.
Our implementation focuses on four core capabilities:
Tool-call interception: Requests are evaluated at the gateway before the protected action is executed.
Deterministic policy enforcement: Defined rules control which actions are allowed, blocked, or sent for review.
Trusted approval boundaries: Client-provided approval claims cannot independently authorize a sensitive operation.
Auditable decisions: Gateway outcomes can be examined to help developers understand why a request was permitted or stopped.
We also integrated an AI proposal workflow to explore how model-generated suggestions can coexist with deterministic security enforcement. The intention is not to eliminate AI's flexibility, but to separate that flexibility from execution authority.
Testing the Idea
We did not want Trapdoor to remain just a security concept or a polished interface. We wanted to test whether the gateway could enforce meaningful boundaries in concrete scenarios.
We created a small local benchmark covering four cases:
A permitted order lookup
A permitted low-value refund
A high-value refund requiring review
A prompt-injection scenario requiring additional scrutiny
All four prototype scenarios passed their expected checks.
In our local benchmark, the baseline configuration recorded a 100% unauthorized-execution rate, compared with 0% for Trapdoor under the tested scenarios. Benign-task completion was 100% in both configurations.
These results are encouraging, but they are early prototype measurements—not proof of production security. The benchmark is small, and broader testing across diverse attacks, tools, and real-world deployments is still necessary.
For us, the important result was demonstrating that a separate policy-enforcement layer can preserve expected benign behavior while preventing the tested unauthorized actions.
The Challenges We Faced
Building a working security prototype in a limited hackathon timeframe involved challenges beyond writing the policy logic.
- Separating AI intelligence from execution authority
One of the most important design decisions was ensuring that an AI-generated response could not bypass the gateway's policy. We had to think carefully about where decisions should be made and which component should have the final authority.
- Handling approval and trust boundaries
A request claiming to have approval should not automatically be trusted. We designed the prototype so that client-supplied approval flags could not independently authorize sensitive actions. A production implementation would need a stronger identity, authentication, and approval-management system.
- Integrating the backend and AI workflow
Connecting the API, policy logic, model integration, and frontend required debugging environment configuration, dependencies, API communication, and response validation. These challenges reinforced the importance of testing individual components before integrating them.
- Balancing security with usability
Blocking everything would be easy, but it would make an agent useless. The more meaningful challenge is to permit legitimate tasks, stop unauthorized actions, and escalate ambiguous or sensitive requests for review.
That balance is what we want Trapdoor to improve.
What We Learned
This project changed how we think about building AI-powered applications.
We learned that AI safety is not only about writing better prompts or selecting a more capable model. It is also about system architecture, trust boundaries, permissions, validation, and controlling what happens after a model produces an answer.
We also learned that security claims need evidence. A convincing demonstration is valuable, but a credible security system must be tested against clearly defined threats and evaluated with transparent benchmarks.
Most importantly, we explored a principle that extends beyond customer support:
Never confuse an intelligent recommendation with an authorized action.
That distinction matters anywhere AI systems can access sensitive data, modify business records, move money, or operate tools on behalf of people.
What's Next?
Trapdoor is a starting point, not a claim that the AI-agent security problem is solved.
Our next steps include:
Expanding the benchmark with more prompt-injection and tool-abuse scenarios.
Adding stronger authentication and a trusted human-approval workflow.
Supporting configurable policies, permissions, and risk levels.
Improving audit records and visibility into blocked or reviewed actions.
Exploring integrations with agent frameworks and real tool APIs.
Evaluating security effectiveness and benign-task performance across a broader range of workloads.
Our long-term vision is to make runtime security a practical, reusable component of AI-agent infrastructure—not something every developer has to reinvent for every application.
Final Thought
AI agents will become more capable. They will access more tools, perform more complex tasks, and operate with greater independence.
The question is not simply whether we can make agents more intelligent.
It is whether we can build systems that let them become more capable without making them blindly trusted.
Trapdoor Gateway is our attempt to move toward that future: a world where AI can act with flexibility, sensitive operations remain governed by explicit policies, and trust is enforced by design rather than assumed by default.
Let AI propose the action. Let security decide whether it happens.

Log in or sign up for Devpost to join the conversation.