VEIL

Runtime authorization for AI agents against untrusted instructions.

Comment

Inspiration

AI agents are becoming capable of taking actions on behalf of users: reading email, accessing files, sending messages, and calling external tools.

That creates a security problem. An agent may encounter instructions from an untrusted source, such as an external email or webpage, and those instructions can influence the action it proposes.

We wanted to explore a simple question:

What if an AI agent could propose an action, but could not authorize that action by itself?

That led to VEIL.

What it does

VEIL is a runtime authorization layer for AI agents.

It sits between an agent's proposed action and the tool that would execute it. VEIL evaluates the proposed action using policy, context, and instruction provenance before execution.

Every proposed action receives one of three decisions:

  • ALLOW — the action is authorized and can execute.
  • REVIEW — the action requires explicit human approval.
  • BLOCK — the action is unauthorized and cannot execute.

The key design principle is that the AI model is not the final security authority. The deterministic authorization layer makes the execution decision.

How we built it

VEIL uses a Next.js and TypeScript frontend with a Python FastAPI backend.

The backend contains the authorization gateway and deterministic policy engine. The prototype also includes an AI agent integration and simulated tools so that the security boundary can be demonstrated without connecting the project to real user accounts or external systems.

The gateway records authorization decisions with information such as the requested action, instruction provenance, risk, decision, matched rule, and whether the tool actually executed.

For actions requiring human approval, VEIL creates a review ID. Approval is tied to that specific review, and the original action is re-authorized before execution.

Challenges we ran into

The biggest challenge was making the security boundary meaningful rather than simply adding another prompt or classifier.

We had to ensure that the language model was not treated as the final authority, that blocked actions did not execute, and that approval could not simply bypass authorization.

We also had to distinguish between trusted user intent and untrusted external instructions while keeping the prototype understandable enough to demonstrate in a few minutes.

Accomplishments that we're proud of

We built a working end-to-end prototype with a public deployment and a live security demonstration.

The final system demonstrates:

  • Untrusted instruction → BLOCK → tool not executed
  • Authorized action → ALLOW → tool executed
  • Approval-required action → REVIEW → tool not executed
  • Explicit approval → re-authorization → ALLOW → tool executed
  • Authorization decisions → audit records

The backend test suite contains 65 passing tests, and the frontend passes TypeScript checking, linting, and production build verification.

What we learned

We learned that securing AI agents is not only about making models better at recognizing malicious instructions.

A model can still make an unsafe proposal. A stronger security boundary is to make authorization an explicit step between the proposal and the action.

We also learned the importance of being precise about security claims. VEIL demonstrates an authorization pattern and does not claim to provide production-grade process isolation or make an AI agent impossible to manipulate.

What's next for VEIL

The next step would be integrating VEIL with real agent frameworks and production tool systems while strengthening the enforcement boundary.

Future work could include stronger process isolation, persistent tamper-resistant audit storage, per-user operator identity, richer policy languages, and integrations with real email, file, and API tools.

The core principle would remain the same:

An untrusted instruction should not automatically become an authorized action.

Built With

Share this project:

Updates

Submission history