In April 2026, an AI agent deleted PocketOS’s production database and its backups in nine seconds.
PocketOS, whose software runs reservations for car rental businesses, had an agent working on a routine task in the company’s staging environment. When the agent hit a snag, it looked for a way around it and found an overprovisioned Railway API token in an unrelated file. It used that token to delete the production database and the backups stored alongside it in a single call.
The credential wasn’t stolen. The agent wasn’t tricked. It decided deletion would clear the error blocking its task, and nothing evaluated that decision before it ran. What PocketOS needed was runtime authorization. In other words, the agent was doing what it was tasked to do. The responsibility for us as security practitioners is to assess whether your own architecture would hold up to an autonomous agent.
What is credential brokering, and why isn't it enough?
The first move to avoid a rogue agent deleting your database is simple: Don’t give agents broad standing access to credentials. Credential brokering does that. It replaces long-lived passwords with temporary auto-expiring access, granted when needed and gone afterward.
Nothing sits on the host between tasks. The major AI providers all agree, and each recommends a version of this approach:
-
OpenAI prescribes network-layer controls that restrict which endpoints an agent can reach.
-
Google prescribes least privilege and scoped OAuth tokens.
-
Anthropic goes the furthest and prescribes proxy injection, so the agent never touches the credential.
All three AI platform vendors are right, but incomplete in the same way. Every decision gets made before the first command runs, but nothing watches what the agent does once it’s in. A proxy confirms a connection opened and which endpoint it reached. The SQL statement, the SSH command and the Model Context Protocol (MCP) tool call are all invisible.
In April, a valid credential made a request to an approved endpoint. Every check that existed passed.
Authentication wasn’t the failure; authorization was
Runtime authorization closes that gap with policy evaluated at the moment of action, inside the protocol layer and every action tied to a named identity. Ask your cybersecurity vendor the questions below to test whether a solution stops at credential brokering or goes on to runtime authorization.
1. Is the action recorded, or just the connection?
You can’t investigate what was never recorded. One record says an agent opened an SSH session on a production host. The other says which commands it ran. Only one of those lets you know what actually happened.
You’d notice if an agent broke something, since a deleted database is hard to miss. You wouldn’t notice an agent that read a table it shouldn’t have, copied it or changed a config, because none of those actions leave a trace. Those incidents only surface if the action itself was recorded.
Logging that a connection happened meets compliance minimums. Recording the statement, the tool call and identity behind the connection is what incident review needs. Vendors will often claim they have full logging and complete visibility, but neither says what's actually being logged.
You need two things: a database session with the statement that ran, and an MCP session with the individual tool call. Both must be tied to an identity. Runtime authorization records the command, not just the connection.
2. Is authorization evaluated per tool call, or per session?
Approving a session isn’t the same as approving what happens inside it. One MCP session can hold dozens of tool calls. Those calls don’t carry the same risk, but they all run in the same session. Reading a table and deleting a table look the same if the check only happens when the session opens.
Everything inside that session inherits a single approval. That’s what happened in April with PocketOS: the token was valid, so the call went through, and nothing evaluated the deletion on its own. Nothing in that path was built to tell a delete apart from any other action.
Ask this and you’ll usually hear “policy-based access control.” That tells you decisions come from a set policy, not when they get made.
A good test is to deny one tool call in the middle of a live session and leave the session running. Runtime authorization evaluates each call before it runs, so it blocks that command and the agent carries on with what it’s allowed to do. Credential brokering can’t do that. Its only control point is the connection, so the choice is to allow the whole session or end it completely.
3. Is every action tied to a named identity?
Agents usually run under a service account, and often several agents share one. The log names the account, not the agent that acted or the person who set it running. That’s fine until you need to know which one did something.
Without that, you can’t tell where to look when something goes wrong, and an auditor asking who authorized the action won’t accept the name of a shared account. Service accounts aren’t the problem, they’re necessary. Attribution is the problem.
Most vendors will tell you that every action is logged against the service account. That names what acted, not who or what set it running, so ask whether the record goes back further than the account.
Real attribution traces a single action back to the identity behind it, not just the account it used
Runtime authorization ties each action to a named identity: a developer working through an MCP gateway logs under their own identity, and an autonomous agent runs under its own dedicated account instead of a borrowed human credential.
4. Is every protocol covered, or just HTTP?
Your agents don’t only reach web services. They connect to databases, SSH hosts, Kubernetes clusters and cloud consoles. Most agent security tooling was built around HTTP and MCP, because that’s where AI tooling started. That covers a fraction of where your agents go.
If each system needs its own tool, each one comes with its own policy and its own log. Separate policies drift, so the same agent ends up with different limits depending on where it connects. Ask what that agent did yesterday and four tools give you four partial answers.
The answer you’ll often get is “we support MCP.” But MCP is one protocol, and the newest one your agents use. The rest have been in your environment for years. Runtime authorization puts a single enforcement point in front of MCP, SSH, databases, Kubernetes and consoles, so the policy and the record don’t change based on what the agent connects to.
| Credential brokering vs. runtime authorization | ||
| What each answer sounds like | ||
| What you're asking | Credential brokering | Runtime authorization |
| What gets recorded? | The connection and the endpoint | The statement or tool call, and the identity behind it |
| When is authorization evaluated? | Once, when the session opens | Before each call, while the session runs |
| Who is accountable? | A shared service account | The identity behind the action |
| What's covered? | HTTP or MCP | MCP, SSH, databases, Kubernetes and consoles |
How Delinea does runtime authorization
The Delinea Platform answers all four questions with runtime authorization.
Every action is recorded as the statement or tool call it actually was, not just the connection. Policy is evaluated on each call before it runs. Each action is tied to a named identity, and the agent never sees the credential. Delinea injects the authentication at the moment of access, whether that's a vault secret, an IAM role, a certificate or an OAuth token. One enforcement point covers MCP, SSH, databases, Kubernetes and consoles.
Read the whitepaper Beyond Credential brokering: Runtime Authorization for AI Agents for the full comparison.
