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.
Request Community access Explore the six scenarios
Built first for security operations and security automation.
Proposed actionendpoint.isolate
| Trusted resource context | Policy decision |
|---|---|
| Development workstationStandard endpoint | Allow |
| Domain controllerTier-0 identity infrastructure | Deny |
| Production serverBusiness-critical workload | Held |
Held means approval is required. Permission to act is separate from evidence that it happened.
Illustrative policy, using synthetic resources. 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.
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.
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 ReplayExplore 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.
Allow a development workstation, deny a domain controller, and hold a production resource for an authorized human’s review.
The agent claims context that does not match its target. Authoritative evidence determines the decision; the caller’s claim remains a claim.
Split 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.
An agent cannot approve its own request. A provider that mutates and then times out leaves an uncertain operation with capacity reserved.
Preview a draft policy against recorded decisions and inspect what changes. Replay calls no provider and writes no live execution state.
Security, 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.
Start with a bounded evaluation
We review access requests before sending invitations, subject to available capacity. Your tenant starts with synthetic hosts and identities, open incidents and an active policy pack.
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.