Governance
Agentic oversight
Governance and control: the oversight a regulated institution needs, built into the architecture rather than bolted on. Three things a security, risk or procurement reviewer actually evaluates.
Least-privilege access
An agent reaches knowledge as a resolved subject: a deputy bounded by the permissions of the person who launched it, or its own registered service identity, narrowed further by a need-to-know envelope.
- Access is granted through named permissions attached to roles, and checked on the server rather than only hidden in the interface.
- Each workflow carries the knowledge domains it writes to, and a launch that targets a gated domain is checked against the launcher's permission before it starts.
- A register lists each agent with how it runs and how far it reaches, so access can be reviewed agent by agent.
Try it
4/4 rows at least privilege · 0 over · 0 under · click a cell to change
Blast radius stays small
An agent with no launching person and no service identity of its own is denied everything, rather than falling back to wider authority.
Attestable entitlements
Reviewers can see in one register whether each agent acts as a deputy or as its own service identity, and how far it reaches.
Narrowed, not widened
A need-to-know envelope can only take away from what an agent reaches. It cannot add to it.
Governed at the workflow level
Whether work stops for a person is set in the workflow's configuration, and a held run waits for that decision rather than proceeding on assumption.
- Held work is approved or rejected by a person, item by item or in bulk, and the decision history is kept for each workflow.
- How confident a run was is shown to the reviewer, but it never decides whether review happens: a confident run and an uncertain one are held on the same rule.
- Agents call models from several providers, through Amazon Bedrock or through a client's own AI gateway, while the rule for what needs a person stays in the workflow.
Try it
↑ swap it - the controls below stay the same
Pick a request and run it.
The unit of control is the work
The review rule belongs to the workflow, so it applies the same way whichever model runs underneath it.
Human accountability at the gate
Each decision on held work is kept in the workflow's decision history, so it can be retrieved later.
Policy that outlives the model
Change the model and the rule for what needs a person stays where it was, in the workflow's configuration.
Tamper-evident audit trail
Administrative changes, sensitive knowledge reads and agent lifecycle changes are recorded against who made them, in a log built to show any later edit.
- Changes to users, roles, access policies, single sign-on and workflow settings are recorded with who made them, from where and when.
- Entries are hash-chained, so a later edit to the record can be detected rather than silently overwritten.
- Reads of sensitive knowledge are written to the same ledger before any data is returned, naming the reader, and for agent work the agent and the person who launched it.
Try it
chain intact · every entry verifiable
Provable, not just logged
A chained record means a later change to it can be detected, rather than the record being taken on trust.
Attributable to an actor
Each entry names the person who acted, and for agent work the agent and the person behind it.
Who saw what
Who read and changed sensitive knowledge can be reconstructed after the fact, without piecing it together from scattered tools.
How this governance compares with the agent suites. See how we compare, with sources →
See it on a workflow you own.
Bring a real process. We’ll show what your first agentic workflow looks like on the platform.
Promenaut
