SentinelOS: Preflight Intelligence for AI Agents

AI agents can propose. SentinelOS decides what gets committed.

Inspiration

As artificial intelligence evolves from answering questions to performing real-world actions, a new challenge emerges: how do we make sure AI agents don't make harmful changes to operational systems?

AI agents can generate incorrect plans, follow malicious instructions, or act on outdated information. In July 2025, an AI coding agent deleted a company's production database during an explicit code freeze. Traditional AI guardrails help filter unsafe content, but they don't determine whether an entire sequence of actions satisfies real-world operational constraints.

We were inspired by a simple analogy: AI agents should work like software developers working with production code.

Developers submit pull requests instead of pushing unreviewed changes straight to production. Their code passes automated tests, security checks, and approvals before it is merged.

Why shouldn't AI agents follow the same process?

That's why we built SentinelOS, a pre-commit control layer that independently evaluates AI-generated plans before they can change operational systems.

What It Does

SentinelOS is a trusted checkpoint between an AI agent and the system it wants to modify.

Instead of letting an AI agent execute actions directly, SentinelOS requires every proposed plan to pass several independent checks.

1. AI Planning: Amazon Bedrock generates a structured plan from a natural-language instruction.

2. Authorization: Amazon Verified Permissions evaluates Cedar policies to decide whether the agent may perform each proposed action. If the policy service is unavailable, every action is denied.

3. Preflight Simulation: A deterministic simulator runs the entire plan, step by step, against a copy of the current warehouse state. It detects capacity violations, insufficient inventory, restricted destinations, and other invalid operations.

4. AI Replanning: If a plan fails, SentinelOS sends structured feedback to Bedrock so it can propose a revised plan.

5. Human Approval: Higher-risk operations require administrator approval tied to the exact plan, revision, and warehouse-state version.

6. Safe Execution: Before committing, SentinelOS rechecks authorization and state. A single DynamoDB transaction applies the whole plan or nothing, refuses it if the warehouse changed, and blocks duplicate execution.

7. Auditability: Every decision and outcome is recorded, so operators can see what was proposed, rejected, approved, and committed.

Warehouse Operations Demonstration

We demonstrate SentinelOS through an AI-powered warehouse operations environment.

For example, an operator might request:

"Move five packages out of Zone A, preferably into Zone B. Use another zone if necessary."

If the AI proposes moving all five packages into a zone with room for only two, SentinelOS detects the capacity violation and rejects the plan before anything changes.

Bedrock can then use the rejection details to propose a distribution that fits the warehouse's limits. The revised plan is validated again and, because it moves five packages, sent for human approval before execution.

In live runs, Nova Pro often proposes a safe split on the first attempt. Our "Over capacity" scenario shows the rejection path directly.

Our demonstration shows how an AI-generated plan can be authorized and still be operationally invalid, and why permission checks alone aren't enough.

How We Built It

SentinelOS combines generative AI with independently enforced backend controls on AWS.

Amazon Bedrock (Nova Pro): Generates structured plans, and revised plans from validation feedback.
Amazon Verified Permissions: Evaluates Cedar authorization policies independently of the language model.
AWS Step Functions: Coordinates planning, validation, replanning, approval, and execution.
AWS Lambda: Runs the deterministic simulator, the executor, and other trusted backend operations.
Amazon DynamoDB: Stores warehouse inventory, agent records, execution records, and audit history.
AWS Secrets Manager: Stores the key that signs single-use admin actions.
AWS IAM: Enforces least privilege, so only the executor can write inventory.
Amazon API Gateway: Exposes the backend to the application.
React, Vite and Tailwind: Power the operator dashboard, with inventory, plan comparisons, agent controls, and workflow status.
AWS Amplify: Hosts the frontend.
AWS SAM / CloudFormation: Deploys every stack as code.

We built a deterministic whole-plan simulator instead of relying on the language model to judge its own actions. It works on a copy of the warehouse state and evaluates each transfer in order, so it catches combined violations that aren't obvious when actions are checked one at a time.

The execution layer uses warehouse-version checks, plan fingerprints, transactional writes, and replay protection.

Crucially, the AI planner has no permission to modify the warehouse. The trusted backend controls execution.

Results

In our enforcement tests, SentinelOS blocked all 13 unsafe requests and none of the valid ones. 6 of the 13 pass a normal per-action policy check and are stopped only by whole-plan simulation or approval binding. These were hand-written requests run on a local copy of AWS.
A policy check through Verified Permissions takes about 69 ms on the deployed stack, compared with minutes for a human approval.
AWS's own IAM policy simulator confirms that no agent or API role can write the warehouse table. Only the executor can.
More than 500 automated backend tests pass across the team's code.

Challenges We Faced

1. Separating AI Reasoning From Operational Authority

Our biggest challenge was letting the AI generate and revise plans without giving it control over the warehouse.

We separated the Bedrock planner from simulation, authorization, and execution. The model proposes actions, and independent backend components decide whether they can proceed.

2. Preventing Invalid Multi-Step Operations

Checking actions one at a time isn't enough. Several transfers might each look fine against the original inventory but together exceed a zone's capacity.

Our simulator processes the complete plan in order and checks every intermediate state before anything is committed.

3. Managing State Changes During Approval

A plan can be valid when generated but outdated by the time a person approves it.

We bind each approval to a specific plan revision and warehouse version, then check the current state again right before execution.

4. Coordinating Multiple AWS Services

Connecting Bedrock, Verified Permissions, Step Functions, Lambda, DynamoDB, and the frontend required clearly defined interfaces. We froze one shared contract for plans, approvals, and errors early, so four people could build in parallel and keep decisions consistent across asynchronous workflows.

5. Preventing Duplicate Execution

Distributed workflows retry requests after timeouts or network failures. Our executor writes a permanent replay record in the same transaction as the change, so the same plan can never move stock twice.

Accomplishments We're Proud Of

Built a deterministic whole-plan warehouse simulator, supported by 61 passing simulator tests.
Built a DynamoDB data layer covered by 59 tests.
Integrated real Amazon Bedrock planning and feedback-driven replanning.
Deployed the backend workflow with AWS Step Functions and Verified Permissions.
Implemented plan-specific approvals and transactional execution safeguards.
Measured our claims instead of assuming them: an enforcement test, deployed latency, and an IAM bypass check.
Built an operator dashboard that shows warehouse state, proposed plans, validation results, and audit activity.

Our biggest accomplishment is showing that AI-generated plans can be treated as proposals that need independent verification, not commands that must be trusted.

What We Learned

Making AI agents reliable takes more than improving the language model.

We learned how to separate probabilistic AI reasoning from deterministic business rules, use Cedar policies for independent authorization, coordinate asynchronous AWS workflows, and keep shared state consistent when operations overlap.

We also learned that AWS already provides the essential building blocks: authorization engines, database transactions, and workflow orchestrators. The engineering challenge is joining them so that what was proposed, validated, approved, and executed stays exactly the same.

Most importantly, AI systems don't need unlimited autonomy to be useful. They need clear boundaries and reliable execution controls.

Current Limitations

One warehouse, one agent, and one kind of action (moving packages).
In the image prompt-injection demo, reading the image is scripted. The policy rejection is live.
Admin actions are gated by a static shared token through a demo-grade authorizer, not real user logins. The production design uses an Amazon Cognito user pool with an admin group.
Our enforcement tests used hand-written requests on a local copy of AWS. We have not yet measured how often the model itself proposes unsafe plans.

What's Next

Our long-term vision is to extend SentinelOS beyond warehouses into other domains where AI agents affect real business systems:

Cloud infrastructure: Reviewing AI-proposed configuration changes before deployment.
Financial operations: Validating refunds, credits, and transaction limits.
Enterprise workflows: Preventing conflicting or outdated multi-step operations.
Security-sensitive automation: Applying independent authorization and approval to agent-generated actions.

Next, we plan to add real admin logins with Amazon Cognito, a reusable integration interface for other systems, model-generated reliability tests, and deployment inside customers' own AWS accounts.

Our goal is to make SentinelOS a practical control layer for teams building AI agents that touch real operational systems.