Preflight AI

A safety layer for AI agents that simulates API actions before execution, reveals risks and unintended changes, and requires approval before anything reaches production.

Comment

Inspiration

AI agents are rapidly moving from answering questions to taking real actions inside business systems.

They can update databases, change source code, modify permissions, trigger financial operations, call external APIs, and interact with critical infrastructure.

That creates a new kind of risk.

A wrong AI answer can be corrected.

A wrong AI action can change customer records, modify billing, grant privileged access, delete data, expose credentials, or trigger an irreversible production operation in seconds.

Preflight AI was built around one question:

What if every consequential AI action had to prove it was allowed before it could actually happen?

Preflight AI introduces a pre-execution control boundary between autonomous AI agents and the systems they want to change.

Instead of monitoring an agent only after an action occurs, Preflight evaluates the proposed action before execution.

The goal is simple:

Let AI agents move fast without giving them unchecked authority over real-world consequences.

What it does

Preflight AI evaluates an agent's proposed action before execution and produces one of three authoritative decisions:

ALLOW — the action may proceed.

REVIEW — execution remains locked until an authorized human explicitly approves the exact evaluated request.

BLOCK — the action cannot execute.

The control flow is:

Agent Intent → Preflight Evaluation → Policy Decision → Human Approval When Required → Controlled Execution → Audit Evidence

This creates a security boundary at the point where an AI-generated intention becomes a real action.

Why this matters

Traditional AI safety often focuses on what a model says.

Autonomous agents introduce a different problem: what software is allowed to do.

An agent may have access to source control, cloud infrastructure, billing systems, databases, identity platforms, internal APIs, or other powerful tools.

In those environments, detecting a mistake after execution may already be too late.

Preflight moves the control point before the consequence.

The agent may propose an action.

Preflight determines whether that action is allowed to happen.

More than a warning

Preflight AI is designed around server-side enforcement rather than client-side warnings.

A BLOCK decision cannot simply be approved or executed.

A REVIEW decision cannot bypass approval by changing a browser flag.

Human approval is bound to the evaluated request and decision rather than acting as a generic permission to proceed.

Replay and idempotency controls help prevent an already executed request from being reused to trigger the same action again.

Unknown or insufficiently classified actions fail closed rather than being silently trusted.

This makes Preflight a control boundary, not simply a risk-warning interface.

Example

Imagine an AI agent proposes a consequential financial operation:

Refund $25,000 to a customer.

Instead of allowing the agent to call the financial system directly, the proposed action first passes through Preflight.

The policy engine determines that the amount exceeds the autonomous financial threshold and returns:

REVIEW

Execution remains locked.

An authorized human must approve the exact evaluated request before it can proceed.

If the request changes, the approval does not silently authorize the new request.

If approval is missing or invalid, execution remains denied.

For destructive or prohibited operations, Preflight can return:

BLOCK

and refuse execution entirely.

For an action that satisfies the configured policy:

ALLOW

permits the controlled execution path to continue.

Safety and audit architecture

The current backend includes:

  • authoritative server-side ALLOW / REVIEW / BLOCK enforcement
  • deterministic policy evaluation
  • request-bound human approvals with expiration
  • SHA-256 request hashing
  • replay protection
  • idempotency controls
  • PostgreSQL-backed runtime state
  • hash-chained tamper-evident audit records
  • atomic execution completion and audit commit in PostgreSQL
  • OIDC identity verification with audience and authorized-party validation
  • agent and reviewer role separation
  • production TLS requirements for remote PostgreSQL
  • fail-closed handling for unknown actions
  • security headers and request validation
  • gated GitHub execution with explicit allowlisting
  • automated server-side tests
  • GitHub Actions CI verification

A key design invariant is that consequential execution and its corresponding audit evidence must remain consistent.

The PostgreSQL runtime can commit terminal execution state and its associated audit record atomically. If the audit write fails, the corresponding execution-state update is rolled back.

The objective is to avoid a dangerous state where an operation appears successfully completed while its required audit evidence silently disappears.

From prototype to control plane

Preflight began as a hackathon prototype exploring a simple idea: simulate an AI action before allowing it to execute.

As the project evolved, the central challenge became much clearer.

The difficult part was not displaying a risk score.

The difficult part was establishing an enforceable boundary between an autonomous agent's intent and a consequential external action.

That led to a deeper architecture separating:

  • intent capture
  • impact simulation
  • policy evaluation
  • approval
  • execution
  • audit evidence

Earlier prototyping used Xano to explore the data and API workflow.

The architecture then evolved into a dedicated Node.js server-side reference implementation with PostgreSQL persistence, stronger identity verification, replay and idempotency protection, transactional execution/audit integrity, and gated external execution.

Each stage moved Preflight from a visual safety concept toward an enforceable pre-execution control layer.

Real external action boundary

Preflight now includes a gated GitHub execution path designed to demonstrate how the control plane can sit in front of an external system.

The important architectural principle is not GitHub itself.

GitHub represents a broader class of consequential tools that autonomous agents may be allowed to use.

The same pre-execution pattern can potentially sit in front of actions involving:

  • source control
  • cloud infrastructure
  • billing and payments
  • databases
  • identity and access systems
  • CRMs
  • support platforms
  • internal enterprise APIs
  • agent tools and MCP-connected systems

The long-term opportunity is a common authorization boundary for many different kinds of agent actions.

Verification

Preflight includes automated tests covering critical safety invariants, including:

  • BLOCK decisions cannot execute
  • BLOCK decisions cannot be approved
  • REVIEW decisions cannot bypass required human approval
  • approvals must correspond to the correct evaluated decision
  • approvals remain bound to the evaluated request
  • safe ALLOW decisions can proceed through the controlled path
  • replay attempts are rejected
  • idempotent requests remain stable
  • persistent state is handled by the PostgreSQL runtime
  • audit records preserve hash-chain evidence
  • production remote PostgreSQL requires TLS
  • OIDC multi-audience tokens require correct authorized-party validation
  • execution completion and its audit commit are atomic
  • audit persistence failure rolls back the corresponding execution-state update

The goal is not only to demonstrate the happy path.

The project deliberately tests the boundaries an autonomous agent must not be able to bypass.

Buyer and operator demo

A dedicated end-to-end demo now illustrates the complete control lifecycle:

  1. an agent proposes an action
  2. Preflight evaluates it
  3. a prohibited action is blocked
  4. a sensitive action is placed into REVIEW
  5. execution before approval is denied
  6. an authorized human approves the evaluated decision
  7. controlled execution is permitted
  8. replay is prevented
  9. audit evidence records the lifecycle

This demonstrates the central idea in operational terms:

The agent does not directly own the side effect. Preflight owns the decision boundary.

Challenges

The hardest problem was not calling an API.

It was deciding where trust should end.

If an autonomous agent can evaluate its own action, approve itself, and execute the operation, the safety boundary is largely cosmetic.

Preflight therefore treats policy evaluation, human approval, execution, and audit evidence as distinct security stages.

Another challenge was avoiding false confidence.

The project distinguishes between controls demonstrated in the current reference implementation and broader enterprise capabilities that still require external validation and production deployment work.

What we learned

The more autonomy AI agents receive, the more important the final boundary before execution becomes.

AI safety is no longer only about model output.

It is increasingly about authorization.

Who or what is allowed to change data?

Who can move money?

Who can modify infrastructure?

Which actions can an AI perform autonomously?

Which require a human?

Which must never happen?

These questions become critical when agents move from assistants to operators.

Human approval is most valuable when it is technically enforced at the exact point where consequences become material.

Progress

During the hackathon, Preflight evolved substantially from its initial prototype.

The project progressed from a simulated preflight concept toward a server-enforced control plane with persistent state, identity validation, approval binding, replay protection, audit integrity, transactional safety, automated verification, and a gated external execution path.

This progression also changed the product vision.

Preflight is no longer framed only as a tool that warns about risky AI actions.

It is being developed as an authorization and execution boundary for autonomous agents.

What's next

The next major milestone is external validation.

We want to place Preflight in front of controlled real-world agent workflows and measure how effectively it governs consequential actions.

Near-term work includes:

  • additional high-value API and agent-tool integrations
  • configurable and versioned enterprise policy bundles
  • stronger tenant isolation and enterprise authorization controls
  • improved deployment and observability tooling
  • broader audit anchoring
  • independent security validation
  • design-partner pilots

The long-term vision is for Preflight AI to become a universal authorization and execution firewall for autonomous agents operating across cloud infrastructure, source control, billing systems, databases, identity platforms, CRMs, and internal APIs.

AI agents are becoming capable of deciding what they want to do.

The next security question is who decides whether they are actually allowed to do it.

An AI agent may decide what it wants to do.

Preflight decides whether it is allowed to happen.

Built With

Share this project:

Updates

Submission history