Platform/Governance
Agents can act in your real systems without anyone opening a hole.
Reading is the safe half. The moment an agent writes to a CRM or a ledger, the questions are who it acted as, what it could touch, and where the row is that proves it.
The path of one call
Follow a single write from the tool that asked for it.
The checks run in order and the first failure ends the call. Every attempt reaches the audit log, in both directions.
The inventory
Eight controls, and every one of them applies to agents as well as people.
Most of this exists in your stack for human users. None of it was built for a caller with no session that can make four hundred calls a minute.
Identitywho is calling
Five credential surfaces, each granted and revoked on its own, so the same provider connected as a data source and as a tool are two separate grants.
live
Authority for unattended runsmandates
A scheduled run has no human in the session, so it needs a durable, expiring, revocable grant naming the subject it acts for, re-checked against that person's current role on every call.
in build
Role and tenantRBAC
Roles resolve per instance and per project across all four transports, and a denial is written to the audit log rather than dropped.
live
Tool allowlistwhat it may do
Engineering declares the write actions that exist at all.
live
Parameter contractwhat it may send
Each tool declares its shape and its bounds.
live
Egress proxywhere it may reach
Outbound calls leave through a proxy with an allowlist, so a deployed app cannot post your data to an address nobody approved.
live
Cost attributionwhat it spent
Every run is costed and attributable to an agent, a project and a person, down to the tool call.
live
Kill switchstop now
One agent, one skill, or everything at once, revoked immediately without a deploy.
live
Why this stays true as usage grows
The rails are set once. What gets authored on top cannot widen them.
Governance that depends on every author making good choices fails at the tenth author. Here the boundary is structural.
Engineering, set once
The rails
- Connectors and data scopes: what any agent may read
- Governed tools and write actions: what may be done, and what needs an approval
- Roles, tenancy, audit retention, sandbox policy
- Cost attribution per agent, per project and per person, down to the tool call
- Promotion thresholds: the score an agent must hold to run with less supervision
Reviewed once as infrastructure, rather than re-argued for every new request that comes in.
Your experts, every day
The knowledge
- Skills in plain English: how this work is actually done here
- Rules, exceptions and judgment calls, captured where they come up
- Corrections on agent output, each becoming a rule the next run inherits
- Test cases: ten real ones, with the answer you would have given
No code and no ticket. Inside the rails there is nothing here that can widen access.
The other blast radius
An internal app your ops team shipped is code running against your systems.
A tool that lets a non engineer ship an app in an afternoon has, by default, shipped it to a personal account with a secret in the bundle. Every build here goes through the same five stages instead.
01
Build
The app is built on the platform rather than on a laptop, from a commit that is kept.
02
Scan
Static checks on data access, outbound calls and secrets. A finding blocks the build.
03
Compile
Built with a scoped token for the tools this app declared, and no broader credential exists to leak.
04
Sandbox
Deployed to an internal URL, running behind the egress proxy, inside your own environment.
05
Audit row
Who shipped what, when, with which scopes, and what the scan found on the way through.
Agents also need somewhere structured to write.
What your security review will ask
The questions that arrive in every questionnaire, answered here.
The full control set and our subprocessor position live on the trust pages. These are the five that decide whether a review continues.
Where does it run?
Inside your own environment.
What leaves the building?
Whatever you send to the model provider you chose, and nothing else.
Who can an agent act as?
A run a person started carries that person, and its reach is bounded by roles and by the tools that were declared in advance.
How do we stop it?
A kill switch at the level of one agent, one skill, or the whole installation, effective immediately and without a deploy.
What can we prove afterwards?
Every call, allowed or denied, with the caller, the tool, the parameters, the result and the context pack that informed it.
Bring the questionnaire to the walkthrough.
The useful version of this conversation is the one where your security reviewer is in the room and works down their own list, rather than reading ours.