Agents & AI
Give an AI agent real access to your data, with a boundary it cannot cross on its own.
An Authoric agent is an AI that can act on your app — read records, write them, call your handlers — under the same authorization as everyone else, and which stops and asks before doing anything you have marked as consequential.
The problem this solves
The usual way to give an agent access is an API key with broad permissions and a carefully worded prompt. That places the boundary inside the model: the agent decides to behave. Prompts are not a security control, and you discover the failure afterwards.
Here the boundary is outside the model. An agent cannot exceed its policies because the check happens where the request is served, not where the instruction is read.
Three doors, one set of rules
There are three ways to drive an agent, and this is the important part: they are not three systems. They resolve the same policy-derived surface through the same execution core, so a permission change lands on all of them at once.
Orchestrated
Give it a goal in natural language and let it plan. POST /agent/invoke.
Direct tool calls
Call one tool deterministically, no model involved. POST /agent/tools/{name}.
MCP
Point any MCP client at the app and the agent's tools appear.
A tool your policy marks high-risk halts on all three. The direct door is faster, not looser.
Where an agent's abilities come from
You never write an agent a list of tools. Its toolbox is derived from the policies bound to its role:
You give the agent a role
The same kind of role you would give a person.
The role carries policies
tickets:read_list, refunds:create, and so on.
Tools appear
Each granted action becomes a callable tool with a generated input schema.
Revoking removes it
Unbind the policy and the tool is gone — from the loop, from direct calls, and from every connected MCP client.
This is why there is no separate "agent permissions" system to keep in step with your real one. There is only the real one.
What a run looks like
A run is a recorded sequence of steps. Each step names the tool, its arguments, and its outcome, so "what did the agent do" is answerable after the fact rather than inferred from logs.
A run ends in one of a few states:
| Status | Meaning |
|---|---|
running | Working. |
pending_approval | Halted on a high-risk step, waiting for a person. |
done | Finished. |
failed | Stopped on an error. |
aborted | Stopped deliberately. |
pending_approval is a normal outcome, not an error — see Approvals & halts.