Governed automation, enforced by the platform.
Models propose actions. Boundlane Control’s policy layer decides what can execute, under tenant isolation, scoped approvals and tamper-evident evidence. Prompt injection is not a hypothetical for software that reads supplier email and touches a ledger — the defence is that the prompt does not decide.
Every effect is checked outside the model. The prompt cannot authorise anything.
Data and credentials are scoped to your organisation, enforced by the database rather than by code that remembers to filter.
A consequential action waits for somebody holding the reviewing role — and the approval covers that action, not every action like it.
Decisions and effects stay traceable, on a chain that reports its own tampering.
These verbs are refused before the toolbox is consulted. Not gated by a rollout stage, not unlockable by an approval, not overridable by an administrator — a package that declares one gets a tool that is absent. The matcher works on meaning rather than spelling, so update_supplier_bank_account is the same act as change_bank_details and is refused the same way.
Each enterprise function adds its own on top of this baseline; none can subtract from it. A refused call is written to the audit log and escalates the run to a person, so a blocked attempt is evidence rather than silence.
Nothing reaches production on day one.
Every automation starts in shadow, where it records what it would have done and touches nothing. Widening is a decision someone makes on evidence — the runs it already produced — and the stage that governs a run is the one it is deployed at, not the one baked into the package.
| Stage | Writes that actually execute |
|---|---|
| shadow | none — intent is recorded only |
| parallel | low risk |
| limited | low risk, medium risk |
| ga | low risk, medium risk, high risk |
What an enterprise review asks about
Row-level security on every tenant-scoped table, FORCEd so the table owner cannot bypass it either.
- Tested as a non-superuser — a superuser bypasses RLS and would prove nothing
- A silo tenant whose database is unreachable fails; it is never served from the pooled one
OIDC with PKCE and JWKS verification, or SAML. SCIM 2.0 for provisioning and de-provisioning.
- SAML claims read from the signed bytes, so a wrapped assertion is refused
- A replayed assertion is rejected atomically
A consequential write defers to someone holding the reviewing role in your organisation, not an admin account.
- One decision only — two reviewers racing cannot both succeed
- An admin acting without the role is permitted and recorded as an escalation
- The approval that authorised a write is named in the trail, including when the write then failed
Hash-chained: each entry hashes the one before it, so alteration is detectable rather than discouraged.
- Every state change writes an entry, refusals included
- Role grants record who granted what, and what the person held before
- The chain head can be published outside the platform, making a rewrite provable
Envelope-encrypted at rest, opened only at the moment of a connector call. No read path back out.
- Master key can live in AWS or Google Cloud KMS rather than the process
- A connector needing auth fails rather than calling without it
An explicit allowlist per connector, enforced on redirects as well as the first request.
- Private and cloud-metadata addresses refused regardless of the allowlist
- An installed template loses the publisher’s allowlist entirely
Zero-retention model gateway. PII redaction applied when recording, not when displaying.
- Enterprise can bring its own model endpoint
- Erasure enumerates tenant tables from the live schema and clears the trace archive first
Most automations run no generated code. When one does, it executes with Node’s permission model on.
- No filesystem, no network globals, an empty environment
- Pinned by hash at promotion and refused at runtime if the bytes changed
A control nobody tries to break is a claim.
Every control on this page is attacked on each build, by a suite that is itself verified: remove a tenancy check and the run must go red. A test that passes whether or not the control exists is worse than no test, because it is believed.
And it is answerable, not just assertable. Ask who can approve a payment and the platform produces the roster, every grant and revocation that led to it, and a verification that the history has not been edited.
Adversarial, on every build: each route unauthenticated, cross-tenant reads, writes and runs against real objects, a forged session, wrong-role attempts on admin-only controls.
The suite is verified by breaking the product: remove a tenancy check and the probe must fail. A green suite that stays green without the control proves nothing.
Isolation is tested as an unprivileged role against real Postgres. A superuser bypasses row-level security, so testing as one would pass no matter what the policy said.
The first evidence request of any audit, generated on demand: the current roster, every membership change, and whether the hash chain behind it verifies.
Across 174 files, including the policy dispatcher, the promotion gate, egress on redirects, and erasure enumerated from the live schema.
Bring the review. We would rather answer it now.
Every control on this page is visible in the product: open a run and read what the dispatcher did with each call. Bring the questionnaire you already use.
2,143 tests · 174 files · every route probed for authorization · evidence generated per deployment at /api/evidence
Open the console