Every agent through the front door

Most companies we talk to started with one agent. A few months later they have a dozen: an assistant built in Copilot Studio, a coding agent in CI, a script someone wired to the payments API, a helper on every laptop in the sales team. Each one was a good idea. Together they raise three questions nobody had to answer when there was only one.

Did every agent actually ask before it acted, or only the ones that were built to? When an agent says it was allowed, can the system it's acting on check that for itself? And when a decision lands on a real person, a customer or an employee, can anyone tell them why?

This week we shipped twelve changes aimed at those three questions. Here's what they give a company running agents.

No way around the front door

A rule only protects you if the agent has to pass it. So most of this week was about closing the side doors.

• Copilot Studio agents are gated, whether or not they were built to ask. Copilot Studio already lets an organisation send every tool call an agent makes to an outside check before it runs. Deliverd used that hook to screen data. Now it applies your gate rules too. You choose how far it reaches: off, only tools that change something, or every call. A refused call is blocked with the rule's reason. A call that needs a person is blocked with the approval link, and goes through once someone approves it. If Deliverd can't be reached, the call is blocked, not waved through.
• Plain APIs get a gateway, not just MCP servers. Our hosted gateway could already sit in front of an MCP server and hold its credential. It can now sit in front of an ordinary HTTP API too. The agent calls the gateway, never sees the real key, and the routes you name (and every write) are gated before they reach the API. The decision travels with the request in a Deliverd-Decision header, so the API can check it.
• Actions that never asked show up anyway. Gates only see what comes to them. So the systems where actions land can now tell Deliverd what happened: GitHub and Stripe webhooks, or anything that can call the API. Each action is matched against the gates that could have covered it. One with no gate behind it is flagged as ungated, shown under Agents → Agents → Enforcement and on the agent's own page, and counted in the risk indicator for actions taken without the required approval.
• Your AI register can stop an agent. An agent can now be linked to its record in the AI register. Suspend or retire the record and every agent linked to it is refused, at sign-in and at every gate. The register stops being a list that describes your agents and becomes one that governs them.

Identity without a shared secret

A key copied into a secret store, or onto five hundred laptops, is a door that's hard to lock again.

• Agents sign in with their platform's identity. An agent running on GitHub Actions, GitLab CI, AWS, Google Cloud or Kubernetes can sign in with the token its platform already gives it, instead of a Deliverd key kept in a secret. You trust an issuer, an audience and a subject for one agent, and nothing else gets in. For issuers many companies share, like GitHub, the subject has to name your own organisation or project.
• Every device gets its own key. For a fleet, an administrator makes one enrollment token and the device manager hands it to every machine once. Each machine swaps it for its own key, named after the device. One lost laptop means revoking one key, and every gate it asks says which machine asked.

Proof that travels with the action

A yes in Deliverd is only as useful as the system that checks it.

• Decision tokens name the agent they were issued to and can be guarded against replay. The TypeScript and Python SDKs now include DecisionTokens and a one-use guard (claimOnce in TypeScript, claim_once in Python), so the service about to act can check the token offline, at the call site, and refuse to use the same one twice. It doesn't have to trust the agent, or call back to us.

The right people, and proof they read it

• Requests go to the asker's manager. Directory sync from SCIM and Google now keeps each person's manager. A rule stage can name the asker's manager, or the manager of the person who made the agent that's asking. If there's no manager on record, it falls back to owners and admins and says why.
• Read and acknowledge. When a new version of a report or an approved prompt matters, an owner can ask named people or groups to read that exact version by a date. They confirm it under To read, reminders go to whoever hasn't, and the list downloads as evidence.

Prompts and reports where people already work

• Approved prompts in chat. /prompt in Slack, prompt in a personal chat with the Teams app or its message extension, and /prompt in a Google Chat direct message bring the version your organisation approved into the conversation. Each use is recorded.
• Reports in Microsoft 365 search. The Copilot connector already made your knowledge and prompts findable in Microsoft 365. It can now include published reports too, granted only to readers Microsoft can name. A report restricted to people Microsoft can't see is never indexed.
• A library that's looked after. People can say whether a prompt worked, and the owner can draft the next version from that feedback. You can require a second approver, tell everyone who used a prompt when it's been replaced, and see what changed in the library this week.

The person on the other end

When an agent's work refuses a refund, declines an application or closes an account, the person it affected may be owed an account of it. Deliverd already holds what they're owed: what was decided, whether a person took part, and the reasons.

• An explanation page for them. From a decided approval, someone in your organisation can make a private link to a plain page for that person. It says what was decided, whether a person or your rules decided it, the main reasons, and how to ask for it to be looked at again. It starts as a draft from the record and is edited before it's shared, so nothing internal goes out by accident. It can also be made through the API by the system that told them the outcome.

What it adds up to

Put together, a company running agents gets something it couldn't easily build for itself: one front door that every agent has to use, however it was built, wherever it runs. Proof of each decision that the receiving system can check on its own. And a record that reaches all the way to the person the decision was about.

We've tested all of this against each platform's published documentation. We haven't yet run it inside a customer's Copilot Studio, Slack, Teams, Google Chat, GitHub, Stripe or cloud account. If you'd like to be one of the first, tell us and we'll set it up with you.