Inspiration
As AI assistants become more capable, they are increasingly connected to tools that can access files, retrieve sensitive information, and perform actions on behalf of users.
But what happens when an external document contains instructions that the user never authorized?
This is the problem of indirect prompt injection. An AI assistant may encounter malicious instructions hidden inside otherwise useful content.
I wanted to make this security problem visible, understandable, and interactive rather than explaining it only through technical articles or static diagrams.
That idea became BoundaryLab — Permission Before Action.
What it does
BoundaryLab is an interactive AI-security learning environment that demonstrates why untrusted information must never become trusted authorization.
Users can explore four scenarios involving an invoice, a retrieved wiki page, a shared document, and harmless content.
Its main features include:
- Guarded vs. Unguarded: Compare two simulated authorization policies on the same input.
- Live Experimentation: Edit documents, remove malicious instructions, impersonate authority, and immediately observe changes in the results.
- Scoped Permissions: See why authorizing one specific action does not authorize unrelated actions.
- Interactive Walkthrough: Explore the authorization process through a React Flow diagram showing trusted requests, untrusted content, proposed actions, and policy decisions.
- Evidence Investigation: Trace blocked actions to their original source lines and understand why they were denied.
- JSON Evidence Export: Download structured evaluation results for further inspection.
Everything runs as a deterministic educational simulation. No real emails are sent, files are deleted, or privileged tools are executed.
How I built it
I used Devpost's Learn Skill Pack to structure the development process, from defining the project scope and product requirements to planning the technical architecture and implementation.
BoundaryLab's core is a deterministic JavaScript policy engine that evaluates candidate actions based on their origin and authorization scope.
The application uses HTML, CSS, JavaScript, React, React Flow, and Vite.
A shared session store keeps the Lab, interactive graph, and Evidence page synchronized, so changes made in one part of the application are reflected throughout the experience.
The project is deployed using GitHub Pages and GitHub Actions.
During development, I continuously refined the interface, moving from an initial workbench to a five-page interactive experience designed around clarity, experimentation, and accessibility.
Challenges I faced
One major challenge was transforming a complex cybersecurity concept into an experience that someone unfamiliar with prompt injection could understand.
Early designs contained too much technical information and too many controls on a single screen.
I addressed this through multiple design iterations, improving visual hierarchy, simplifying interactions, and introducing progressive disclosure.
Another challenge was keeping the authorization graph, policy decisions, and evidence records consistent as users edited the input.
I also had to ensure that the simulator clearly distinguished hypothetical outcomes from actual execution, avoiding misleading security claims.
Accomplishments that I'm proud of
I'm particularly proud of turning an abstract security principle into a working, interactive experiment.
Instead of simply telling users that prompt injection is dangerous, BoundaryLab allows them to observe how an injected instruction changes the proposed actions—and how authorization controls affect the outcome.
The application includes synchronized policy comparisons, an interactive authorization graph, source-linked evidence, responsive interfaces, and automated testing.
Most importantly, its interface was refined to make the underlying security lesson easier to understand.
What I learned
Building BoundaryLab reinforced the importance of separating instruction detection from authorization enforcement.
A suspicious instruction is not automatically an authorized action, and a document claiming to have system-level authority does not actually gain that authority.
I also learned the importance of directing AI-assisted development through clear requirements, documented decisions, iterative testing, and continuous human review.
Good software isn't just about implementing features. It's about making those features meaningful and understandable to the people using them.
What's next for BoundaryLab
Future improvements could include more realistic scenarios, additional authorization policies, richer educational challenges, and optional integration with controlled AI-agent environments.
Another potential direction is allowing developers to model their own tool permissions and experiment with different authorization strategies.
BoundaryLab is not intended to replace production security controls or guarantee protection against prompt injection.
Its purpose is to help developers and cybersecurity learners understand the principles behind safer AI-agent design.
The core lesson is simple:
A document can provide information. But only trusted authorization should determine what an AI assistant is allowed to do.
An instruction isn't permission.
Log in or sign up for Devpost to join the conversation.