01
Agent workspace
- permitted read context
- Runner Key for submitting requests
- no target-system write token
- no adapter private key
Security model
The agent can propose work. It holds neither the write path nor an unrestricted read path.
An agent can read permitted context and prepare a structured request. But the credentials and code path that can change a target system stay behind the boundary.
Impact Boundary Core checks the request against current state, local policy, allowed scope, required evidence, and required next action before any work can reach an adapter.
Credential boundaries
The write credential stays away from the agent.
Across adapters, the split is intentionally simple: the agent can read permitted context and propose work, but write credentials stay with the Gateway or adapter host. Target-specific credentials should remain outside the agent environment.
02
Boundary / Gateway
- policy and state checks
- scoped target credential
- admission decisions
- outcome recording
03
Target system
- reviewable or auditable impact path
- operator review where required
- no direct agent write path
- target-side protections still matter
Admission checks
Before impact can leave, the request has to match the boundary.
A proposed action is not allowed just because the agent produced it. The Core checks whether the request still matches the current system state, whether it fits policy and scope, and whether the required evidence is present.
01
Policy fit
Does this request match the local rule set for this target system?
02
State freshness
Is the request based on current state, or does the agent need to read again?
03
Scope
Is the requested change inside the allowed branch, path, action type, or target boundary?
04
Evidence
Does the request include the evidence needed before impact can continue?
05
Required next action
If the request cannot continue, the boundary returns what needs to happen next instead of silently producing impact.
06
Human review
When review is part of the target workflow, admitted work still has to remain reviewable. The model does not remove human judgment.
Security boundaries
The boundary separates decision, materialization, provisioning, visibility, and failure behavior.
01
Admission boundary
The Core decides whether proposed work may continue. Blocked, conflicting, or incomplete requests stop before external impact.
02
Fail-closed boundary
When state is stale, evidence is missing, scope does not match, or the adapter cannot safely materialize work, impact stops.
03
Adapter boundary
Adapters connect real systems, but they should not decide admission or accept arbitrary agent commands that bypass the Core.
04
Provisioning boundary
Setup and admin credentials stay server-side or local. Browser clients and public surfaces should not receive administrative tokens.
05
Visibility boundary
Operators should see decisions, outcomes, and required next actions. Raw secrets, private keys, payloads, diffs, and source contents should not be exposed in public UI.
User data boundary
Trust also depends on what the website does not collect.
Product security is not only about agent credentials. Visitors also need a clear line between public-site analytics, contact emails, and any sensitive adapter or target-system data.
01
Minimal website analytics
The public site uses Plausible for aggregate page measurement. No marketing cookies, cross-site tracking, user accounts, individual profiles, or advertising identifiers.
02
No secret collection
Website analytics must not receive tokens, Runner Keys, private keys, payloads, diffs, repository contents, or private demo data.
03
Runtime data stays separate
Website analytics is separate from adapter and runtime data. Local or self-hosted evaluation should not send product telemetry back to Impact Boundary Labs.
Known limits
What this does not claim
A boundary is useful, but it is not magic. It controls where impact authority sits; it does not make every agent action correct.
- It does not prove generated code is semantically correct.
- It does not replace human review.
- It does not auto-merge.
- It does not give agents target-system write credentials.
- It does not make arbitrary target adapters trusted by default.
- It does not protect against write paths that bypass the Gateway or adapter.
- It does not make a compromised host safe.
- It does not expose payloads, diffs, source contents, private keys, or tokens in public UI.
- It does not claim production security certification.
Need to evaluate the exact security model?
Start with the Core docs for admission behavior and adapter docs for target-specific credential handling, data boundaries, visibility, and known limitations.