Identity tells you who. Authority tells you what's allowed.
When your agents start buying, ordering or changing things at vendors, the first question has good answers. These ten are about the second. Ask them of your own teams, and of every vendor your agents will touch. They apply whatever tools you use.
1. Who authorized this agent to act, and can the vendor see it? Why: the vendor is the one acting on the request, and it can't see your internal approvals. A good answer: the agent carries a permission your company issued, and the vendor checks it before acting.
2. What exactly may it do? Why: an agent with broad access will eventually use it for something nobody intended. A good answer: a written scope (which actions, which resources, which vendors) that's checked on every request, not just at setup.
3. How much, per action and in total? Why: a card limit caps one card, but not invoices, credits, or orders spread across vendors. A good answer: a limit enforced at the vendor for each action, plus a total you watch across all of them.
4. Until when? Why: permissions outlive the project they were written for. A good answer: every permission has an expiry, and an expired one is refused, not quietly honored.
5. How do you revoke it at every vendor, and how fast does that land? Why: shutting down a misbehaving agent shouldn't mean phoning each vendor or canceling a shared card. A good answer: one revoke that every vendor's next check will see, and you've practiced it.
6. What happens when the checker is down? Why: "allow when unsure" turns an outage into an open door. A good answer: the check fails closed (a deny or an error, never an allow), and the vendor's integration does the same.
7. Can a stolen credential be replayed, or used beyond its scope? Why: agent keys leak like any other secret. A good answer: each request is bound to one vendor, one action and one moment, can't be replayed, and can't exceed the permission it came with.
8. What evidence remains after the action, and who can verify it? Why: when a vendor or an auditor asks "who allowed this?", logs that only you can vouch for are your word against theirs. A good answer: a signed record of each decision, kept for a stated period, that the other side can check for itself.
9. Does the check cover actions that aren't card payments? Why: invoices, net terms, data pulls and configuration changes never touch a card limit. A good answer: the same authority check applies whatever the rail, or whether money moves at all.
10. Who holds the signing keys, and what happens when they rotate? Why: a record is only as trustworthy as the key that signed it. A good answer: keys held in hardware, published so anyone can verify, and rotated without invalidating the records already signed.
If a team or a vendor can answer all ten plainly, you know where you stand. If not, the gaps tell you where to start.
We built Delegus to make these questions answerable: delegus.ai/why.