What it does
You build an agent from a template, decide what it may touch, who may run it and what it may spend, put a person in front of anything sensitive, and then read back everything it did. Each of those is one screen, and nobody has to learn more than the one they use.
What you can build today
Five shipped templates. IT access changes your directory today and the leaver sweep reads it; the other three decide and record, because the systems they would change are ones we do not connect to yet. Authoring a brand-new agent type still takes us, and we would rather say so than imply a blank canvas.
- IT access
- Someone asks for a system, a drive or a licence in plain language. The request reaches the person you named, and approved access is added to the group in your directory, for a period if the reviewer chooses one.
- Leaver
- A departure is found by a scheduled sweep of your directory, and every group the person still holds is listed with a reason. Today it reports; taking the access back is a reviewer's action from the access page.
- Snowflake access
- The same decision path, pointed at a warehouse. The decision and its record are real; carrying it out in Snowflake needs a connector that does not ship yet.
- SaaS seats
- Requests for a paid seat, decided against your rules and recorded. Not provisioned, for the same reason.
- VPN access
- Network access as a request with a rule behind it rather than a message to whoever is around. Decision only, today.
In the beta every request an organization sets up goes to a person. The gate can clear low-risk requests on its own; that path is built and not yet switched on for customers.
Screen by screen
Building an agent
Pick one of the shipped templates and it becomes yours: a name, an owner, a department. Each change you make afterwards is a version rather than an edit, so you can approve one, reject one, or roll back to the last that worked.
Deciding what it may touch
Every version carries its own list of tools, drawn from a registry of servers and the specific tools on each that were approved. The check happens at the gateway rather than inside the prompt, and every call is recorded against that list, whether it went through or not. New organizations start with the list closed.
Deciding who may run it
You name the people or the groups. Somebody outside that list does not get a refusal at the end of a run: the agent is not in their picker, and the attempt is recorded if they try anyway.
Deciding what it may spend
A budget per agent, and a list of models best first. As spend approaches the cap the run steps down the list to a cheaper model instead of failing, and each step-down is written to the record. The reservation and the choice happen in one step, so two runs at once cannot both take the expensive option. Whether an agent at its cap is warned or refused is your setting; your organization's monthly cap is enforced at the gateway regardless.
Putting a person in the loop
You mark what needs a human. Those runs pause and survive a restart, and the approver decides from an emailed link or a Teams card on their phone, seeing what was asked, who asked, and for how long, before the buttons. The link is deliberately thin: it reaches an inbox, and an inbox is an archive, so the whole thread does not travel with it. Approving says what it is about to change before it changes it.
Access: who holds what, and when it ends
Every approval that landed in your directory is a row with a start, an end if one was chosen, and who decided. When the period ends the membership is removed in Microsoft 365 or Google Workspace and the person is told. A reviewer can take access back early from the same page. The list exports.
Reading it back
A plain-language timeline for the person who asked: what was understood, which rule applied, who decided, what changed. Administrators can open any step for the model used, what it cost, the policy excerpts retrieved and the tool calls made, and export the whole record.
Checking before you publish
Before a version goes live it is run against your own past cases and checked for the things that break agents quietly: a tool that is not reachable, a connector whose credentials expired, a policy that resolves to no legal model.
What it connects to
Connectors are built and run by us, with your credential, against your own site or tenant. Each tool a connector exposes is reviewed before any agent may call it. Plugging in your own MCP servers is not supported yet.
- Microsoft 365 and Google Workspace
- People, groups and memberships. Read to build the catalog and the audiences; written only after an approval, and to take access back.
- Jira and Confluence
- Read only, through a connector we wrote and run, with an API token you issue against your own site. Each tool it exposes is approved before an agent may call it.
- Teams, Slack and email
- Where an agent's output goes: an approval card in Teams, a summary in a Slack or Teams channel, an email to a group. Slack is a destination for summaries, not yet a place to approve from.
Who does what
Three roles. Members ask and see their own requests and what they hold. Reviewers decide, and can take access back. Administrators set up the organization, the catalog, the agents and their limits, and can see everything in it. Connecting a directory, a connector or a channel is its own permission, because those decide how the organization reaches the outside.
What stops it going wrong
- The rules decide, not the model
- The model reads the request and works out what is being asked for. Whether it is allowed is decided by your policy, which is why the same request always gets the same answer and why we can show you the reason.
- Retrieved context is advisory
- Past approvals and policy excerpts are pulled in and shown to the person deciding. The gate itself ignores them, so nothing a document says can talk an agent into a yes.
- Acting is for the verified person
- Access is granted to the signed-in person, not to a name typed into a sentence. Asking on someone else's behalf is an administrator's action.
- Nobody approves their own request
- A reviewer who asked for something cannot be the one who clears it, and the attempt is recorded.
- Your data stays yours
- Every row carries the organization that owns it and the database enforces the boundary, not the application code. Our own operators read across organizations through a read-only role, and those reads are logged.
The security page says how the boundary is enforced, where data lives, and who processes what.
Try it on your own directory
Setup is about fifteen minutes and needs an administrator once. A larger organization can start with a pilot instead.