Buttons. Forms. Wizards. Session auth. Implicit guardrails baked into the UI.
That works until an AI agent needs to do real work in the same product.
Then teams usually do one of two things to allow AI agents:
- Hand the agent an API key
- Wrap the product in a chatbot and hope the model behaves
Neither solves the hard part.
The hard part is not access. It is execution.
Can this caller read that record?
Can it update this field?
Does this action need a person to approve it first?
If something goes wrong, can you reconstruct what happened?
An API key answers none of that.
It only answers: "can this thing reach my backend?"
That is why we keep saying agents need gates, not keys.
A gate is a declared rule:
- what actions exist
- who can invoke them
- when consent is required
- what gets logged
Duct was dogfooded this on **Whistler **with two callers on the same policy:
- a human using the embedded Shell
- a third-party agent calling the same actions
Same manifest. Same permission checks. Same approval on side effects. Same audit trail.
No master API key for either.
If you are adding agents to a product that was built for humans, the question is not "do we expose an API?"
It is: "do we have a governed execution layer for every caller?"
I wrote up how we built that layer, with demos: blog/accountable-agents
Top comments (0)