Impact Boundary Labs

Control agent impact before it happens.

AI agents no longer just answer - they act: they change code, files, and real systems. Impact Boundary is the line in between.The agent can think and propose, but a check decides what actually becomes real.

Why this exists

An agent said done. A file was gone.

How do we let agents work without letting them directly control impact?

The obvious reaction is: do not give agents credentials.

But that only removes usefulness. If an agent cannot reach tools, it cannot do useful work.

The boundary keeps the tool path useful, but checks the point where a request becomes a real effect.

Agents can ask.

The boundary checks.

Only admitted work reaches the tool.

Why now

The risk is shifting from wrong answers to wrong outcomes.

When models only produced text, the main risk was a bad answer. Agents now inspect code, call tools, and operate inside real workflows - so the question is no longer whether an answer is correct, but whether proposed work should become real impact.

Aviation

Pilots need clearance

A useful pilot still works through clearance before a real aircraft changes course.

Software

Developers need review

A useful developer still works through review before protected changes ship.

Finance

Operators need authorization

A useful operator still needs authorization before sensitive actions become real.

Ability does not remove process.

First concrete example

A valid tool call can still be the wrong effect.

Your agent can request a tool action. That does not mean the effect should execute.

Valid tool call

The agent requests a tool action.

The tool call matches an available tool and has the right shape.

Observed runtime fact

The checked state is stale.

The request was prepared against old state, so the proposed effect no longer matches what is true now.

Boundary result

Execution stops before downstream change.

No file, repository, workflow, database, or target system changes unless the Core admits the request.

The boundary blocks execution before the downstream system changes.

Product surface

MCP Boundary

A local boundary for selected MCP tool calls.

Local Windows binary.

Local Email Demo included.

Add a local MCP server, copy the Boundary entry, and inspect Tools, Policy, and Activity in the dashboard.

Interactive demo

Connect an agent and watch the boundary decide.

Impact Room is a small reference environment where an agent can observe state and propose actions, but cannot directly trigger the final effect.

The Core

The Core decides what agent work becomes real.

The Core is the engine that makes the decision. The agent sends what it wants to do, what it currently sees, and any evidence. The Core checks all of it and decides, before anything can change a real system.

Agent intent
Agent

Submits intent.

Boundary decision
Boundary

Checks policy, state, and evidence.

External impact
Decision
AdmittedExternal impact
BlockedNo impact
ConflictRe-check state

Admitted continues. Blocked has no impact. Conflict requires re-check.

The rules are open to build on, but control stays yours. Credentials, policies, and approvals never leave your side of the boundary.

Build your own adapter, connect your own tools, or share the pattern with others.

Adapter host

Bring your own target system. Keep the boundary.

Every team has different systems: repositories, databases, APIs, local tools, workflows, or internal services. Adapters connect those systems to the Core without giving the agent a direct write path.

Adapters expose state, receive admitted work, and return outcomes. They do not decide admission. The Core does.

submit-intent.ts
policy.go
worker.ts

Adapters can run as local binaries or Docker Compose services.

Put a boundary between your agents and real systems.

If agents are doing real work for you, the question is what may become real impact. Tell us what you are connecting - or start local with MCP Boundary.