TRUST IS ARCHITECTURE
AI governance and security are design decisions here, not a policy document written after launch. Every agent has a written limit on what it may do alone. Every irreversible action passes a person. Every action it takes is logged, and the log is yours.
What AI governance and security mean for an autonomous agent
AI governance and security for an autonomous agent means four things you can inspect: a written boundary on what the agent may do without a person, an approval gate on anything it cannot undo, a complete record of what it did, and a way to stop it immediately.
An agent is different from a model in exactly the way that matters here. A model produces text. An agent takes actions in your systems, with credentials, on a schedule, without anyone watching.
So the controls below are not about the model’s output. They are about what happens between the model deciding something and your system changing because of it.
Every agent has a written limit
Each agent carries a boundary agreed at the blueprint stage, before any code exists. The boundary names what it may do alone, what it must propose for approval, and what it may never do at all.
Boundaries are enforced in the tool gateway, not in the prompt. An agent cannot exceed its permissions by being persuaded, because the permission check happens outside the model.
A typical support agent may answer, tag and route alone. It may propose a refund. It may never issue one.
Anything irreversible passes a person
An approval gate is a named person, a real decision and a recorded outcome. The agent presents what it wants to do, why, and what it read to get there. The person approves, edits or rejects, and the outcome is stored with the task.
Gates sit on anything that moves money, changes a customer record, sends something under your name, or cannot be reversed by another action.
Approval fatigue is a real failure mode, so gates are tuned during release rather than set once. If a gate is approving 99 of every 100 proposals unchanged, that is evidence to widen the boundary, and it is a decision you make with the numbers in front of you.
Every action is reconstructable
Every agent action writes an audit entry: the trigger, the inputs it read, the model calls it made, the tools it called with what arguments, the result, and the confidence or eval score attached.
Entries carry a correlation id from intake to outcome, so a single customer complaint six months later can be traced through every agent that touched it.
The audit store is yours. It is queryable by your team without us, and it survives the end of an engagement.
Your data, your boundary
You choose where inference runs and where indexes live: your cloud, our cloud, or a split. The architecture is identical in all three.
Retrieval indexes are built inside the boundary you choose. Documents are not copied out of it to be embedded. Where a source system holds permissions, those permissions are carried through to retrieval, so an agent answering for one person cannot surface a document that person could not open.
Personal data is detected and handled before indexing rather than after an incident. What we retain, for how long and on what legal basis is set out in the privacy policy.
Agents never hold your credentials
Secrets live in a managed store. Agents call tools through a gateway that holds the credentials, applies per-agent permissions, validates arguments against a schema, rate-limits and logs the call.
The practical consequence is that “what could this agent possibly do?” is answered by reading a permission list, not by reading a prompt and hoping.
Access is scoped per agent and reviewed at each release. An agent that no longer needs a permission loses it, which is the control most often skipped and most often exploited.
Your data is not training data
We contract for zero training rights with every model provider we use, and we prefer deployments where your data never leaves your tenancy. Where a provider’s terms cannot meet that, we route the task to one that can.
Model choice is a routing decision governed by an eval suite, so a provider change is a controlled event with a pass or fail attached, not a silent substitution.
Our full position on model vendors, training data and transparency is on the AI governance page.
What happens when an agent gets it wrong
Agents fail. The question a governance page has to answer is what the failure costs and how fast it stops.
Every hive has a kill switch that stops one agent or all of them without a deployment. Actions are designed to be reversible where the underlying system allows it, and where they are not, they sit behind an approval gate for exactly that reason.
Failures are classified. Known classes get a known fix and a retry. New ones raise an alert with the full trace attached, the agent stands down, and the work routes to a person rather than queuing behind a broken step.
Where the failure is in your infrastructure rather than the agent, that is its own discipline: self-healing infrastructure agents.
The commitments behind the controls
Controls describe what a system does. Commitments describe what we will not build, whatever the brief says.
Ours cover autonomy limits, human oversight, how we treat training data, which model vendors we will work with, what we disclose when an agent has produced something, and what we do when an agent causes harm.
Frequently asked questions
Do you hold SOC 2 for your AI agents?
No, and we say so before you ask. We hold no third-party attestation today. The control set an auditor would examine is in place and described on this page: scoped credentials, an approval gate on irreversible actions, a complete audit trail, incident classification and a documented vendor policy. If your procurement process requires an attestation, we are not the right supplier yet, and we would rather you learned that on this page than in week six.
Can our data be used to train a model?
No. We contract for zero training rights with every provider we use, and we prefer architectures where your data does not leave your tenancy at all. Retrieval indexes are built inside your boundary. Where a provider's terms cannot meet that commitment, the task routes to one that can, and that routing decision is recorded.
Who is accountable when an agent makes a mistake?
You keep accountability for decisions made in your business, which is why the approval gates exist and why they sit on anything irreversible. We are accountable for the system behaving as designed: the boundary holding, the log being complete, the escalation firing. When a failure is ours, the trace shows it, which is the point of keeping the trace out of our hands and in yours.
How quickly can we stop an agent?
Immediately, and without a deployment. The kill switch operates per agent or across the whole hive, and it is tested during release rather than assumed. Work in flight stops at the next safe point and routes to a person, with everything the agent had already gathered attached.
Do you have access to our production systems?
Only where an engagement requires it, only through scoped credentials held in your secret store, and only for the agents that need them. Our engineers work against your non-production environments by default. Where production access is unavoidable, it is named, time-bounded and logged like any other access.
What happens to our data and agents if we stop working with you?
You keep them. The agents, their configuration, the eval suites, the runbooks and the audit history are yours, and the runbooks are written for a reader who is not us. Handover is a stage in the process rather than a negotiation at the end of one. See how an engagement runs and the managed option if you would rather we kept operating it. - **secondary line:** Questions this page does not answer? Ask us directly.