An agent that can delete things will delete things
Exposing an API so a model can call it takes an afternoon. The hard part is everything after: an agent retries, improvises, and acts on behalf of someone whose permissions it does not have. We build the layer that makes that safe, and provable afterwards.
Talk to an engineerWhen teams call us
- An agent was given a tool that writes, and now nobody can say which changes came from a person and which from the model.
- The agent retried after a timeout and the operation ran twice. It was a payment.
- Tool access is scoped to the integration, not to the user who asked, so the agent can reach data the person could never have opened.
- The model calls a tool with arguments that are valid JSON and nonsense, and the system does them.
- There is no ceiling: one bad loop and the agent spends the month's budget before lunch.
- Someone asks what the agent did last Tuesday and the answer is in a chat transcript, not in a log.
What we build
Permissions that follow the person, not the integration
The agent acts on someone's behalf, so it must be able to do exactly what that person can do and nothing more. Scoping access to the integration is the default and the mistake: it makes every user as powerful as the most powerful one.
Operations that survive a retry
Idempotency keys on everything that writes, so a repeated call is harmless instead of expensive. Agents retry on timeout by design, and a timeout does not mean the operation did not happen.
A bounded blast radius
Destructive operations behind confirmation, limits on how much a single session can change, and a defined way to undo. The question is not whether the agent will do something unintended; it is how much that costs when it does.
Interfaces a model can actually use
Tool descriptions and schemas written for a reader that has no context, plus errors that say what to do instead of what went wrong. A vague description produces a confident wrong call.
Attribution that holds up later
Every action recorded with the agent, the model version, the human it acted for, and the input that triggered it. This is the same evidence problem as the rest of AI in production, with an extra actor in the chain.
Typical projects
Expose an existing system to agents, safely
An MCP server or tool interface over what you already run, with permissions, idempotency and limits designed in rather than added after the first incident.
Audit an agent integration already in production
Find what the agent can reach that it should not, what happens on retry, and what evidence exists of what it did. Fixed scope, written report.
Add attribution to agent actions
Retrofit logging so every change is traceable to the agent, the model version and the person behind it.
Put a ceiling on agent spend
Budget limits that stop rather than warn, per session and per period, with defined behaviour when the ceiling is reached.
What you get
- A tool interface your agents can use and your security team can explain
- Permissions derived from the requesting user, demonstrated with tests
- Idempotency on every write path, with the retry case covered
- Spending and rate ceilings that stop rather than notify
- A log where every agent action names the model, the human and the trigger
Questions we get asked
Is this just MCP?
MCP is one way to expose the interface, and a good one. But the protocol is the easy half: it standardises how a model discovers and calls your tools, not who is allowed to call what, what happens on a retry, or how you prove afterwards what was done. Those are the parts that break.
Our agent only reads. Do we still need this?
Read access is where the permission problem bites hardest. If retrieval is not scoped to the requesting user, an agent that only reads can still assemble an answer from documents that person was never allowed to open — and it will do it convincingly.
How is this different from the auditable AI systems work?
Same evidence problem, one more actor. There, the question is what the model saw and produced. Here, an agent also acts: it changes things. So attribution has to answer not only what was said but what was done, by whom, on whose behalf.
The standards are moving. Is it too early?
The protocols are moving; the failure modes are not. Permissions, idempotency, blast radius and attribution were the hard parts before agents existed and will be after the protocol changes name. Building against those is not a bet on a standard.
Start a conversation
Tell us what you are building, or what is currently breaking. You will get a straight answer from an engineer, not a sales script.