Permit
Technical capability is not authority.
An agent may hold the capability that updates a proposal and still be bound by a policy that caps discounts at ten percent. The permission system decides whether it can act at all; the policy engine decides whether this particular action is within its authority. Both have to pass.
Two checks, not one
First: does this agent hold this capability? Then: is this specific action inside the limits set for it? A system with only the first check will happily let an agent offer forty percent off.
Limits are values, not prose
A maximum discount, a maximum credit, a maximum daily spend, a list of customers that always require a human. Checked numerically before the call rather than described in a prompt and hoped for.
Exceeding authority produces a request, not a refusal
An agent that needs eighteen percent and may offer ten asks for the difference and explains why. The useful behaviour is escalation, not failure — but the escalation is mandatory.
Authority can follow the company's own structure
Where a connected workforce system already records who may approve what, agent authority can be derived from it rather than maintained twice. Two copies of an approval matrix will disagree within a month.
Permissions
The rest of this area.
Three states per capability, and the default is never.
Grants and scopes
Allow, approve or never — per capability, per agent.
Boundaries
What an agent can never do, however it is configured.
Permission reviews
Access granted for a reason that expired is the common failure.
Secrets
Agents never hold credentials. Ever.
Network policy
Where an agent may reach, and nowhere else.
Give AI a job.
Build an agent, choose what it can access, define what it may do, and deploy it to work safely across your business.
No code required · Full SDKs and API · Stop any agent instantly · [email protected]