Give an AI agent a key to your business, and keep the last word
Every serious conversation about AI inside a business system ends at the same question: what stops it. Not what it can do — what happens the first time it is confident and wrong at three in the morning. Our answer is structural rather than a promise about the model: an assistant connected to Alef can read, and it can ASK for a change, and it cannot make one. A write it requests is recorded as a proposal and waits for a person who holds the permission that write requires. Approving replays the action under the identity the assistant was acting for — so an agent is never a way around anybody's permissions, including the approver's.
An agent can ask. Only a person can commit.
When an assistant calls a tool that would change data, nothing is written. The capability layer records the request as a proposal and answers the assistant plainly: a human must approve it before it takes effect. There is no setting that turns this off, no trusted agent that skips it, and no difference between an agent you connected yesterday and one that has run for a year.
- A write is recorded as a proposal, never executed on the agent's say-so
- The assistant is told it is waiting on a person, so it does not report the job as done
- Reads run immediately, and every one of them is audited
It cannot ask for something it could not have done
Permission is checked BEFORE the system decides whether the call is a read or a write. An agent that is not allowed to raise a purchase order does not get a rejected proposal for one — it never creates the proposal at all. The approval queue is a place where allowed work waits for a decision, not a channel for asking someone else to do the forbidden.
- The tenant must hold the app the capability belongs to, or the call is refused
- The capability's own permission is checked against the person the agent acts for
- A refusal is written to the audit trail with the permission that was missing
Approval is a decision, not a rubber stamp
Approving a proposal requires the permission that the write itself requires — the person clicking Approve must be someone who could have done it by hand. On approval the action replays under the identity the assistant was acting for, so the record shows whose authority was used and who agreed to it. The two are never the same field.
- An approver without that permission is refused, whatever their job title
- Approved actions run as the person the agent acted for, tagged as an approved agent action
- Rejecting takes an optional reason, and the reason is kept with the proposal
A queue you can actually read, and an audit trail behind it
Pending proposals are one screen: what capability, what arguments, who or what asked, and when. The decided ones do not disappear — approved, rejected and failed are three more views of the same queue, which is what makes this reviewable after the fact rather than only in the moment.
- The proposed arguments are rendered readably, so a reviewer judges the action and not raw JSON
- Approved, rejected and failed stay visible, with who decided and when
- An approved action that then fails is recorded as failed, with the error — not quietly dropped
Off until you turn it on, and revocable after
The whole agent surface sits behind a switch in your own settings, off until you decide otherwise. A connection an assistant uses is a scoped token that a security administrator issues, sees exactly once, and can revoke — the same shape as the API keys on our API page, and administered in the same place.
- One tenant-level switch controls the agent surface for the whole account
- Issuing or revoking a connection requires the security administration permission
- The connection secret is shown once at creation and never again
What AI agent governance runs on
Hold this on its own, or add the modules beside it when you want them — they share one login and one set of records. See the module library and pricing.
- Included with your account — there is no governance module to buy
- Works across whichever apps you hold
Questions buyers ask
Can an AI agent change data in our system?
Not on its own, and this is enforced in the capability layer rather than promised by a prompt. A write is recorded as a proposal and the assistant is told a human must approve it. A person then approves or rejects it on the decision queue. So an agent can draft a purchase order or book an appointment for you to confirm; it cannot post one while you sleep.
Who is allowed to approve what an agent proposed?
Whoever holds the permission that the write itself requires — approving a purchase order proposal needs the same permission as creating one by hand. Anyone else is refused, including administrators who have not been granted that permission. This is the part that matters: if approval were a generic “can approve AI things” right, an agent plus a junior approver would together be a way around your permission model.
Whose identity does the action run under once approved?
The person the assistant was acting for, not the approver, and the action is tagged as an approved agent action. The approver is recorded separately, with the time of the decision. Two names on one record is the point — you can answer both “whose authority did this use?” and “who agreed to it?” without inferring either.
Can an agent read things it should not see?
It is bound by the same two gates as a person: your account must hold the app the data belongs to, and the identity it acts for must hold the permission that data requires. A denied attempt is written to the audit trail with the permission that was missing, so an agent probing at the edges is visible rather than silent.
What happens if an approved action then fails?
It is recorded as failed, with the error, and stays in the queue where you can see it. An action that could not run at all — a network fault mid-flight, say — leaves the proposal pending rather than half-applied, so it can be approved again once the cause is fixed. What does not happen is a proposal quietly marked done because a button was clicked.
How do we switch this off, or cut off one assistant?
The agent surface is behind a switch in your settings and is off until you enable it. Each assistant connects with its own scoped token, issued by a security administrator and shown exactly once; revoking that token cuts off that assistant without touching anyone else. There is no shared credential to rotate across everybody.
See it running
Create an account, or tell us how you work today and we'll show you what AI agent governance looks like on your data.