BOUNDARY: AI That Asks Before It Acts

A policy and approval layer for AI agents that turns plain-English company rules into enforceable actions—allow, redact, route privately, require approval, or block—with a complete audit trail.

Comment

Inspiration

AI agents are moving beyond answering questions. They can read records, call tools, update systems, process requests, and communicate with customers.

That creates a critical question: how does an organisation decide what an AI agent is actually permitted to do?

Many agent restrictions still exist only inside prompts. A company may tell an agent not to expose personal data, issue large refunds without approval, or send external emails without permission—but a prompt alone is not an enforcement boundary.

BOUNDARY was built to place a deterministic control layer between an AI agent’s intention and its real-world action.

What it does

BOUNDARY converts plain-English company policies into structured rules that can be reviewed and confirmed by a human.

Every proposed action is then evaluated by deterministic code and receives one of five decisions:

  • Allow — the action is permitted
  • Redact and allow — sensitive fields are removed before processing
  • Route privately — the action must use an approved private path
  • Require approval — execution pauses for a human decision
  • Block — the action is prohibited

The demonstration focuses on a customer-support workflow involving personal information, refunds, private transcripts, external emails, and destructive tool requests.

For example:

  • A small refund can be allowed automatically
  • A ₹7,500 refund requires human approval
  • Personal information is removed before a cloud action
  • Sensitive transcripts are routed privately
  • External communication requires approval
  • Attempts to delete the audit history are blocked

Every step is recorded in an ordered audit timeline containing the attempted action, applicable rule, enforcement decision, approval state, transformation performed, and simulated outcome.

All tools, refunds, emails, customer records, and actions in the hackathon demo are synthetic or simulated.

Try to Break My Policy

BOUNDARY also includes an adversarial policy-testing workflow.

GPT-5.6 can propose possible bypass attempts, such as splitting a large refund into smaller transactions or disguising an external email as a preview action.

Those suggestions are non-authoritative. They are reviewed and converted into bounded test scenarios before the deterministic policy engine evaluates them.

The public demo also includes committed adversarial fixtures so judges can test this workflow without an API key.

The resulting report shows which attacks were blocked and whether any policy gap escaped enforcement.

How we built it

BOUNDARY was developed with Codex as the primary engineering environment.

Codex helped implement and validate:

  • The Next.js and strict TypeScript foundation
  • Structured Zod policy and action schemas
  • The deterministic enforcement engine
  • Human confirmation and approval workflows
  • Approval binding to exact actions and policy versions
  • Redaction and private-routing transformations
  • Simulated tools and safe audit events
  • GPT-5.6 integration through the official OpenAI Responses API
  • Adversarial policy testing
  • Session persistence using Upstash Redis
  • Request throttling, safe errors, health checks, and deployment hardening
  • The judge-ready workspace and submission documentation
  • A test suite containing 89 passing automated tests

GPT-5.6 is used only for bounded language tasks:

  • Interpreting plain-English policy into a structured proposal
  • Producing non-authoritative adversarial suggestions

GPT-5.6 cannot approve an action, activate a policy, write authoritative audit events, or invoke a tool.

A human must confirm the interpreted policy, and deterministic code remains the final enforcement authority.

Challenges

The main challenge was separating natural-language understanding from enforcement.

Language models are useful for understanding intent, but permissions involving refund limits, protected data, approvals, external actions, and destructive operations need predictable and testable behaviour.

BOUNDARY therefore treats model output as an unconfirmed proposal. A human confirms the policy, and deterministic code owns all enforcement decisions.

Another challenge was creating a realistic workflow without connecting the hackathon project to real payment, email, CRM, or customer systems. We solved this by using simulated tools and synthetic records while preserving the complete approval and audit flow.

During deployment, the local Windows patch helper also failed because of a sandbox limitation. After explicit approval, controlled PowerShell file writing was used only inside the authorised repository. The final project was validated with linting, TypeScript checks, 89 automated tests, a production build, and live Vercel testing.

What we learned

Agent safety cannot depend only on better prompts.

Teams need a clear boundary where actions can be transformed, routed, paused, approved, or blocked before execution.

We also learned that model output, human authority, policy compilation, action evaluation, approval state, and tool execution should be represented as separate system boundaries rather than combined into one agent prompt.

What’s next

The hackathon version focuses on customer-support operations, but the same control layer could later protect:

  • Finance and refund agents
  • HR assistants
  • Healthcare workflows
  • Sales automation
  • Internal knowledge agents
  • Developer and deployment agents
  • AI systems connected to email, CRM, payment, or database tools

Future work would include signed policy versions, distributed rate limiting, enterprise identity, real connector sandboxes, policy simulation across historical actions, and formal compliance exports.

BOUNDARY: AI that asks before it acts.

Built With

Share this project:

Updates