AI agents spending money went from a demo to the news in a single week. SAP made SAP Pay generally available, so payments run straight out of the ERP when an invoice comes due. Meta’s agent Muse now connects to QuickBooks, Stripe, and Shopify. Sierra and Meta announced an open standard for how personal agents sign into businesses. And Elon Musk told people they can buy things with Grok by taking a picture of their credit card and dropping it in the chat.
Every one of those stories comes down to one question: whose permissions is the agent running on?
Whether you’re approving an AI rollout, building the workflows, or testing them, you’ll get asked that question. Once software can release cash, the answer stops being a technical detail. It’s an internal control question.
The two answers
A service key (or service account) is an identity that belongs to the application or workflow itself. You set it up once, give it a set of permissions, and every time it runs, it runs with exactly those permissions. It doesn’t matter who clicked the button, or whether anyone clicked it at all.
User-based authentication (or delegated access) works differently. A person signs in, and the agent acts on that person’s behalf with that person’s access. If you’ve connected Claude or ChatGPT to your drive, SharePoint, or email by signing in as yourself, you’ve already used it. The AI can only see what you can see.
Neither is wrong. Both have a place.
Why this didn’t matter as much before
Service accounts aren’t new. When I was at PwC setting up Alteryx servers and UiPath bots, well before generative AI, service accounts were the standard way to run automated workflows that weren’t tied to any one person.
That worked because those bots were deterministic. They did the same thing every time. An auditor could test the bot once and rely on that test in later years. PCAOB AS 2201 allows that kind of benchmarking for automated controls, but only if the access and change controls around the program are effective.
An AI agent isn’t a hardcoded program. It decides its own steps each time it runs. You can’t rely on the logic staying the same, so you have to rely on the boundaries: who is this, and what is it allowed to touch?
When to use each one
User-based authentication is the right default when a person is in the loop. Chatbots, copilots, an assistant that pulls a report when you ask. The agent can never do more than the person using it, so if a staff accountant can’t see payroll, neither can their assistant. Your existing role design and segregation of duties carry through, and the log ties the action to the human who asked for it.
Think of it like a company card. When your assistant books travel on your card, it’s your name on the statement and your spending limit. You can give them a lower limit, but they can’t spend more than you can.
Service keys are the right choice when no one is asking. Scheduled agents, overnight reconciliations, a payment run that fires on the due date. Forcing user-based auth onto those jobs usually means hardwiring the job to whoever set it up. When that person leaves, the job breaks or keeps running on their credentials.
A service key is the dedicated virtual card you set up for a recurring vendor. It has its own limit, it charges whether anyone’s in the office or not, and someone in AP owns it.
Where it goes wrong
The problem isn’t service keys. It’s shared, broad service keys with no owner. Gravitee’s 2026 survey found 45.6% of teams still use shared API keys to authenticate their agents, and only 21.9% treat agents as their own identity-bearing entities.
When four agents share one key, the log records the key. It doesn’t tell you which agent acted. That’s the office card that sits in a drawer and everyone borrows. When the statement comes in, nobody can tell you who bought what.
For SOX purposes, this lands in logical access. A shared key across agents makes it very hard to show who can do what, or to test segregation of duties. That’s a conversation you want to have before go-live, not at interim testing.
Key takeaways
- Ask whose identity it’s using. If nobody can tell you whether an agent runs on a service key or a user’s identity, that’s your first finding.
- Use user-based auth when a person is in the loop. Give the agent the user’s permissions or fewer, never more.
- Use service keys when no one is in the loop, with one key per agent, scoped to the job, short-lived, and owned by a named person.
- Never share a key across agents. If the log can’t separate them, you can’t attribute actions or test segregation of duties.
- Put a human at the decision point. Let the service identity run routine steps. Keep new vendors, bank detail changes, and anything over a threshold tied to a real person’s credentials.
Here’s the test for your next AI rollout: if someone is asking the agent to do something, it uses their card. If no one is asking, it gets its own card, with its own limit and a named owner. It never gets the card in the drawer.
Want the CPE credit? Take the full lesson on EverydayCPE and earn 0.2 CPE credits: Whose Permissions Is Your Agent Using?
Leave a Reply