AI Agent Security
The agent proposes. ExecBound decides.
Control consequential actions across security agents and automation using trusted enterprise context, shared impact limits, and deterministic policy outside the model.
Sign up for Community Explore the six scenarios
Built first for security operations and security automation.
Proposed actionendpoint.isolate
| Trusted resource context | Policy decision |
|---|---|
| Development workstationStandard endpoint, critical incident open | Allow |
| Domain controllerTier-0 identity infrastructure | Deny |
| Production workstationTrading desk, critical incident open | Held |
| Production serverA server: the isolation permit covers workstations only | Deny |
| Workstation, incident closedIts incident was closed after review | Deny |
| Host the agent calls a workstationThe request claims criticality 1 | Deny |
| Workstation with an expired recordInventory last observed it outside its freshness window | Refused |
| Host not in trusted inventoryNo resource or alias resolves | Refused |
Held means approval is required. Refused means the request failed closed before policy, because the target or its required trusted context could not be established. Permission to act is separate from evidence that it happened.
Fig. 1 · Illustrative: synthetic targets under ExecBound’s SOC demonstration policy. Every allow, deny and held was computed by the product’s Cedar engine when this page was built, and a refusal is the answer resolution gives before policy; your browser only looks it up. This is not live activity.
Agent Action Control Plane
A workflow may need to isolate one compromised workstation. Its service account may be able to isolate every endpoint. A prompt asking the agent to avoid critical systems does not narrow that credential.
ExecBound evaluates the action, target and trusted context before a protected action can execute. Bound what AI agents can do, even when their credentials can do more.
Instruction inside the model
“Contain the incident. Don’t disrupt critical systems.”
Controls outside the model
Example policy on an ExecBound-protected Execute path.
Current action catalog
endpoint.isolateendpoint.lift_isolationidentity.disableidentity.enableidentity.revoke_sessionsidentity.reset_passwordOptional learning examples use controlled mocks. Catalog entries do not establish real-provider coverage.
How it works
One decision model for MCP, HTTP and integrated execution checkpoints.
Authenticate the caller. Map the request to a canonical action and resource. Unknown consequential actions fail closed.
Read trusted context, apply deterministic policy and reserve impact. Caller claims cannot satisfy required trusted facts. Missing or stale required evidence stops dispatch.
Allow, deny or require a named human’s approval. On protected paths, recheck authority before execution and retain the result with its evidence.
Count affected targets across agents, runs and protocols within the configured principal and tenant limits. Atomic reservations keep simultaneous requests from each spending the same remaining capacity.
Both agents isolate hosts under the SOC demonstration rules. Each may isolate 10 hosts an hour on its own; after that a person must approve. The workspace as a whole may isolate 20 in any 15 minutes; after that every request is denied.
0 of 10 autonomous isolations used
0 of 10 autonomous isolations used
0 of 20 used
No requests yet.
Fig. 2 · Illustrative: the SOC demonstration pack’s two isolation limits, simulated in your browser with no request to anything. ExecBound itself counts them under one lock per workspace, so simultaneous requests cannot each spend the last unit.
Choose the action path
Start with visibility, connect an existing executor, or route protected actions through the ExecBound gateway. Each path carries its own evidence and enforcement mode.
Monitor
Gate
Execute
Fig. 3 · Each path carries its own evidence and enforcement mode; the rows below describe each one in full.
Understand recorded activity
Bring in observations and authority evidence from connected systems. See the activity and authority evidence ExecBound has for each recorded action path, its enforcement mode, and the gaps that remain unknown.
Visibility without prevention. Observations do not authorize actions, settle provider outcomes or prove that every bypass path is known.
Keep your existing executor
An existing gateway or workflow asks ExecBound for a decision bound to the exact request, reserves impact, executes with its own connector, and reports the outcome.
The executor keeps its credentials. Enforcement depends on a proven blocking control point. A skippable check remains advisory; an executor’s report is not independent provider proof.
Use the protected gateway
Agents call ExecBound over MCP or HTTP. ExecBound holds the upstream credentials, applies policy, and dispatches through its controlled execution path.
A protected credential boundary. Enforcement covers the documented routes whose credentials and execution cannot be bypassed by the agent.
Control and Gateway
Control brings policy, trusted context, approvals and shared impact limits to a common decision layer. Gateway provides the MCP and HTTP execution boundary. Integrated checkpoints connect that decision layer to an existing executor.
Start with endpoint containment and identity response across SOAR, agents and automation. The architecture centers on identities, actions, resources and context, so the control plane can extend beyond security operations as new paths are qualified.
Test a candidate policy against retained decision history. Compare decisions using the recorded context without calling a provider or changing live budgets, approvals or execution state. Missing historical evidence stays unresolved.
Provider timeouts may leave an outcome uncertain. ExecBound keeps that uncertainty visible and requires sufficient evidence before a retry or refund.
Read about evidence and ReplayThe agent asks to isolate ws-trade-0031, a production workstation. A permit matches and the approval set asks for a named person’s review, so nothing is dispatched. A pending approval reserves no impact.
The agent calls the approval route for its own request. An agent credential cannot approve, deny or change configuration, so the attempt is rejected and audited.
An analyst with approval scope for this target approves. The approval is for this agent, action, target and plan only. Its expiry was fixed when the request was held: when the plan’s trusted context stops being valid, or earlier if the workspace sets an approval deadline that comes first.
Authority and context are checked again, the approval is consumed by one execution claim, and the isolation is dispatched once. It charges one unit to the workspace total and none to the agent’s autonomous allowance.
A retry with the same idempotency key returns the result it already has: no second mutation and no second unit. The same action sent under a new key is a new request, decided and counted again.
Had the target’s trusted facts changed before the retry, re-attestation would find a different binding. The approval would be stale and the request would end as STALE_AUTHORIZATION; to try again, the agent sends a new request, which is decided on the facts as they are then.
Suppose the provider isolated the host and then timed out. ExecBound records the outcome as uncertain: the impact stays charged, nothing is resent, and the outcome stays uncertain until evidence settles what happened.
Fig. 4 · Illustrative: one request’s lifecycle under the SOC demonstration pack, with synthetic names. Permission to act and evidence that it happened are separate records.
+ forbid(principal, action == ExecBound::Action::"endpoint.isolate", resource)
+ when { resource.is_production };| Recorded request | Recorded | Replayed |
|---|---|---|
endpoint.isolate on ws-dev-0142Development workstation | Allow | Allow |
endpoint.isolate on ws-trade-0031Production workstation | Held | Denychanges |
endpoint.isolate on dc-01Domain controller | Deny | Deny |
identity.disable on j.ortizStandard user, critical incident | Allow | Allow |
identity.disable on svc-paymentsProduction service account | Held | Unresolvedit would need a person's approval, which nobody recorded |
identity.reset_password on m.chenStandard user, high-severity incidentrequire_change_at_next_sign_in: true | Allow | Allow |
identity.reset_password on j.ortizStandard user, critical incidentrequire_change_at_next_sign_in: false | Held | Unresolvedit would need a person's approval, which nobody recorded |
endpoint.isolate on ws-old-0007Workstation, recorded before context capture | Allow | Unresolvedits context was never captured |
1 decision certainly changes, 4 stay the same, and 3 are unresolved: Replay will not assume an approval nobody recorded, an action nobody observed, or context nobody captured. It called no provider and changed no live budget, approval or execution state.
+ forbid(principal, action == ExecBound::Action::"identity.disable", resource)
+ when { resource.is_production };| Recorded request | Recorded | Replayed |
|---|---|---|
endpoint.isolate on ws-dev-0142Development workstation | Allow | Allow |
endpoint.isolate on ws-trade-0031Production workstation | Held | Unresolvedit would need a person's approval, which nobody recorded |
endpoint.isolate on dc-01Domain controller | Deny | Deny |
identity.disable on j.ortizStandard user, critical incident | Allow | Allow |
identity.disable on svc-paymentsProduction service account | Held | Denychanges |
identity.reset_password on m.chenStandard user, high-severity incidentrequire_change_at_next_sign_in: true | Allow | Allow |
identity.reset_password on j.ortizStandard user, critical incidentrequire_change_at_next_sign_in: false | Held | Unresolvedit would need a person's approval, which nobody recorded |
endpoint.isolate on ws-old-0007Workstation, recorded before context capture | Allow | Unresolvedits context was never captured |
1 decision certainly changes, 4 stay the same, and 3 are unresolved: Replay will not assume an approval nobody recorded, an action nobody observed, or context nobody captured. It called no provider and changed no live budget, approval or execution state.
- (resource.incident_severity == "HIGH" || resource.incident_severity == "CRITICAL")
+ resource.incident_severity == "CRITICAL"| Recorded request | Recorded | Replayed |
|---|---|---|
endpoint.isolate on ws-dev-0142Development workstation | Allow | Allow |
endpoint.isolate on ws-trade-0031Production workstation | Held | Unresolvedit would need a person's approval, which nobody recorded |
endpoint.isolate on dc-01Domain controller | Deny | Deny |
identity.disable on j.ortizStandard user, critical incident | Allow | Allow |
identity.disable on svc-paymentsProduction service account | Held | Unresolvedit would need a person's approval, which nobody recorded |
identity.reset_password on m.chenStandard user, high-severity incidentrequire_change_at_next_sign_in: true | Allow | Denychanges |
identity.reset_password on j.ortizStandard user, critical incidentrequire_change_at_next_sign_in: false | Held | Unresolvedit would need a person's approval, which nobody recorded |
endpoint.isolate on ws-old-0007Workstation, recorded before context capture | Allow | Unresolvedits context was never captured |
1 decision certainly changes, 3 stay the same, and 4 are unresolved: Replay will not assume an approval nobody recorded, an action nobody observed, or context nobody captured. It called no provider and changed no live budget, approval or execution state.
Fig. 5 · Illustrative: eight synthetic recorded requests. Both columns were decided by the product’s Cedar engine when this page was built, under the SOC demonstration pack and under each change.
Explore the six scenarios
These scenarios exercise the kernel against controlled mock providers and synthetic data. No real endpoint or identity provider is changed.
The upstream credential stays inside the protected service. The agent has its own gateway identity and no direct provider authority.
See it in Fig. 3Allow a development workstation, deny a domain controller, and hold a production resource for an authorized human’s review.
See it in Fig. 1The agent claims context that does not match its target. Authoritative evidence determines the decision; the caller’s claim remains a claim.
See it in Fig. 1Split isolation requests across two agents and HTTP and MCP. Each request consumes the same configured tenant capacity; splitting the work does not reset the limit.
See it in Fig. 2An agent cannot approve its own request. A provider that mutates and then times out leaves an uncertain operation with capacity reserved.
See it in Fig. 4Preview a draft policy against recorded decisions and inspect what changes. Replay calls no provider and writes no live execution state.
See it in Fig. 5Security, with the boundaries visible
Enforcement is a property of a tested action path. A connected platform, a successful API call or a signed executor report alone does not prove that an agent cannot bypass the control.
The public documentation records the threat model, architecture and acceptance criteria. The integration register keeps research, fixture tests and bounded platform trials distinct.
Create your Community workspace
Sign up with your email or a supported sign-in provider, then choose a workspace name. Your workspace starts empty, ready for guided setup and optional synthetic examples. New workspaces are subject to available capacity.
Start a persistent Hosted Community workspace with the current three-agent creation limit. Explore optional synthetic examples, then follow guided setup. Self-hosted Community is uncapped.
For security engineering, SOAR and IAM teams, and MSSP/MDR operators evaluating consequential automation.
Tell us which platform you use, which action needs a boundary, and what evidence would let your team trust it.
Become a design partnerOpens an email to the founder.