Governed agents
An agent that can act is only useful in an organisation if you can say who it is, what it may do, who approves what it proposes, and what it did.
A governed agent has five things: an identity of its own, permissions scoped to its job, policy that changes what it can actually do, human approval where the risk calls for it, and a record of every action. This page says what each one means, which parts the platform has built today, and which are design intent.
Guardrails answer one question: should this output or action be blocked? Governance asks more. Who is acting, allowed to do what, under which policy, with which data and model, at what risk and with what oversight, and can you prove it afterwards? An agent is governed when those questions have answers that the platform can enforce and show, rather than answers that live in a document beside it.
That is why the controls sit at the points where an agent acts: before a model call, before a tool call, at each step of a workflow, at network egress and at deployment. A policy that cannot change what the agent actually does is paperwork.
Each is a question you should be able to answer for every agent you run.
Who is this agent, and who owns it? An agent acts as itself, never as the person who built it, so that nobody has to wonder whose access it is using.
What can it reach? Tools and data are granted per agent and per job. Anything not granted is not available, and an agent acting for a person never has more access than that person.
What is it allowed to do right now? The platform policy engine can allow an action, redact content, ask a person, or deny. A later check can tighten an earlier one and never loosen it.
Who decides? Where the risk calls for it, a named person approves before the action happens. A gate that nobody answers does not turn into a yes.
What did it do? Each run leaves a record of the policy decisions, the approvals and the actions, chained so that tampering is detectable.
The Trust Profile is the single record we describe for every AI system: identity, owner, risk level, approved models, data classification, data residency, permitted systems, allowed actions, restricted actions, the human approval rule, retention, audit and policy set. It is the checklist a reviewer reads before an agent goes live. The platform page shows a worked example, and this page does not repeat it.
Here is the honest position. The Trust Profile as one record that the platform reads and enforces is design intent. Today its parts exist as separate controls: the policy engine, the approval gates and the run ledger. You can keep the profile as a document next to each agent and make the controls match it, and the template pages below are written in that shape.
Autonomy is earned in steps and set per agent and per action. It is never a switch from manual to autonomous.
AI recommends.
A human approves.
AI acts within limits and is monitored.
AI works independently within strict policy and risk bounds.
AI improves within controlled boundaries.
The five levels are the framework we use to decide how much approval an agent needs. In the platform today there is no single setting called L3. You choose a level by choosing the controls: which actions go through an approval gate, which tools are allowed, and which runs are monitored. An agent at L2 has a gate in front of every action. An agent at L3 has gates only in front of the actions above your threshold, and a person watching the rest.
A level should only move up on evidence and should move down when the evidence turns. Our rollout post sets out a practical plan for that. Treat the level as a decision you record, not a label that does the work for you.
Our coding agents run with Nexus capture, so their actions are recorded. Inside Cortex, a coding agent can read files without asking and must ask for everything else, and a prompt that nobody answers is a deny. Sending, paying, deleting, pushing and running shell commands always need a person. That is a small, real instance of the pattern on this page. The story of how we build is on its own page, with a status on every practice.
Built means the product can do it today. Designed for means it is the intended design and is not built yet. We give no dates.
| Practice | Status | What we can point to |
|---|---|---|
| Policy engine: allow, redact, ask, deny | Built in the product | Wired into every workflow node and the gateway tool loop. It is enforced for runs that have a policy attached. A self-serve way to author policies is not something we describe as built. |
| Human approval gates | Built in the product | Gates are addressed to a person, nudged, escalated to a named fallback and parked. They never auto-approve. Approvals exist in several parts of the platform, not yet in one shared inbox. |
| Run ledger with a hash chain and a verify call | Built in the product | Records policy decisions, approvals and actions per run. A seal of the chain head exists and is opt-in. There is no dedicated export yet. |
| Per-agent tool allow and deny | Built in the product | Blocked tools and run limits are enforced for Workers. In Cortex, tool calls are approved one by one, bound to the exact call. |
| Trust Profile as one record the platform enforces | Designed for | The fields are defined. The record that the controls read from is not built. |
| Autonomy level as a setting | Designed for | The levels are a framework. Today you realise them through approval gates and tool permissions. |
| Owner, risk level and approver on an agent record | Designed for | Not built as fields on the agent. |
| Platform-enforced rule that the approver is not the requester | Designed for | Not enforced today. You apply it when you assign each gate. |
How to read the status
Each example lists what the agent can do, what it cannot, what needs a person to approve, and what it records. Eight more are on the templates page.
Prepares purchases for approval. It reads, compares and drafts, and it never approves or pays for anything itself. This is the worked example used across the platform pages.
Starts at: L2 Approve: a person approves each purchase it prepares.
No ready-made template ships yet. The shape is the one the platform pages describe.
| Can | Cannot | Requires approval | Records |
|---|---|---|---|
|
|
|
|
Reads a support ticket and the order history, and recommends whether a refund is warranted. A person or a payments system issues it.
Starts at: L1 Assist, moving to L2 Approve for refunds once the recommendations are reliable.
The agent wizard includes a customer-support sample, and workflows have a human-input step you can use as the approval gate. The refund policy and gate are yours to add.
| Can | Cannot | Requires approval | Records |
|---|---|---|---|
|
|
|
|
Procurement, refunds, access review, change and release approval, incident response, vendor onboarding, KYC, DPIA intake and policy attestation. The page says which have a starting point today and which are designed.
An agent with an identity of its own, permissions scoped to its job, policy that changes what it can do, human approval where risk calls for it, and an audit record of what it did. The controls apply while the agent runs, and they are not left to a document.
Guardrails decide whether one output or action should be blocked. Governance covers who is acting, under which policy, with which data and model, at what risk and with what oversight, and whether you can prove it afterwards.
The Trust Profile is the record we describe for every AI system. The single record that the platform enforces is design intent. Today its parts exist as separate controls: policy, approval gates and the run ledger. You can keep the profile as a document and make the controls match it.
It should not, and approval gates never approve on their own or on a timeout. A platform check that the approver is a different person from the requester is designed for and not built yet, so today you enforce it by how you assign each gate.
Start at L1 Assist or L2 Approve, and move up only on evidence from the level below. Many agents should stay at L2 or L3 for good, because the right level depends on risk and how reversible the action is.
No platform can do that on its own, and we do not claim it. Swfte provides the technical controls, governance mechanisms and evidence required to deploy AI within an organisation's applicable regulatory, security and policy requirements. The exact posture depends on the customer's use case, jurisdiction, deployment and configuration. This is not legal advice.
Start with one entry point. Add intelligence, agents, workflows and infrastructure as you prove value.
One platform for the agents, models and workflows your team ships. Free to start, no card required.