When AI Agents Go Wrong: Authentication, Data Ownership, and the Governance Gap

Here is a failure mode that is becoming familiar across the industry, even when the names change: an AI agent is wired up to “just get the integration working.” Someone pastes a long-lived API key or an OAuth token into its environment, the demo works, and it ships. Weeks later the agent is doing more than the original task — it has been reused by another workflow, it is calling a tool nobody reviewed, or a prompt-injected instruction quietly redirects one of its calls. The token never expired, never had its scope narrowed, and was never tied to a specific human’s authority to begin with. By the time anyone asks what did this agent actually do, and on whose behalf, the honest answer is a shrug and a pile of disconnected logs.

That is not a hypothetical corner case. It is what happens by default when you give a fast, unattended, instructable piece of software the same kind of credential you’d hand a person — and skip the parts of identity and access management that made human authentication survivable: expiry, scope, and a record.

A credential broker is the piece of infrastructure that closes that gap. It sits between your AI agents and your real secrets, so the agent never holds a standing key, every call is checked against policy before it happens, and every call is written to a record you can prove wasn’t altered afterward. That one sentence is the rest of this post, unpacked.

Why the old login handshake doesn’t fit an agent

The login handshake we all know — enter credentials, get a session, stay logged in — was designed around a human sitting at a keyboard: one identity, one device, roughly one action at a time, and a person who notices when something looks wrong. Agentic AI breaks every one of those assumptions at once:

• It acts fast and unattended. A human’s leaked password does damage for minutes before someone notices. An agent loop can make thousands of calls before anyone looks at a dashboard.
• Its instructions are attacker-reachable. Prompt injection means the thing deciding how to use a credential can be steered by text the agent merely read — a webpage, a document, another agent’s output.
• It fans out. One agent calls another, which calls a tool, which calls an API. A single login at the top of that chain tells you almost nothing about what happened three hops down.
• It has no instinct for “this looks wrong.” A person mid-handshake notices an unfamiliar prompt or a suspicious redirect. An agent follows the protocol exactly as written, including the parts an attacker engineered.

None of this means agents shouldn’t authenticate. It means the handshake has to produce something different from what it produces for people: not a session that outlives the task, but a short-lived, narrowly scoped credential, minted for one job, that is nearly worthless the moment it leaks. We’ve written before about what a modern agent handshake looks like in practice with MCP and OAuth 2.1 — discovery, PKCE, a bearer token scoped to specific tools, no secret ever pasted into the model. That protocol layer is necessary. It is not, by itself, sufficient.

The question authentication alone can’t answer: whose data is this?

Proving who an agent is doesn’t tell you what it should be allowed to touch — and that second question is really a question about data ownership. Every record in your systems belongs to someone: a customer, a department, a tenant, a specific human user. An agent authenticated as “the support bot” might be perfectly legitimate and still have no business reading another customer’s invoices, another team’s HR records, or a dataset outside the scope of the task it was actually given.

Data ownership is where a lot of “AI agentic gone wrong” stories actually originate. The agent wasn’t unauthenticated — it had a valid token. It was unscoped: authenticated as a principal, but not bound to the specific records that principal’s request actually concerned. A support agent answering ticket #4821 should be able to reach the data behind ticket #4821. It should not be one broad database credential away from every ticket, every customer, and every table the underlying service account happens to touch.

Resource-level scoping is what turns “authenticated” into “authorized for this data, right now”:

• Audience — which upstream API or MCP server the credential is valid for.
• Operations — read, not write; this endpoint, not that one.
• Resources — specific records, paths, or object IDs, not the whole dataset behind them.
• Lifetime — minutes, tied to the task, not months.
• Rate — a ceiling that contains a runaway loop before it becomes an incident.

Get those five right and a leaked or misdirected credential is worth very little — it expires almost immediately and only ever opened a small, data-owner-specific door. We go deeper on this pattern in scoped credentials for AI agents.

Governance needs proof, not policy documents

A well-written access policy that nobody can verify in production is not governance — it’s a PDF. Real governance for agentic AI rests on three things happening for every single call an agent makes:

• Control the action. The agent can only do what policy says it may, and that check happens before the call, not in a postmortem.
• Attribute the action. You can name the exact agent, the credential it used, and the human or system it was acting for — not “a service account did something.”
• Record the action. Every call lands in a log you can trust wasn’t edited after the fact, because logs that can be quietly rewritten aren’t evidence, they’re a suggestion.

That third point is where observability and traceability stop being separate concerns from governance and become the same concern. A governance program that can’t point to a tamper-evident record of what an agent did is asserting compliance, not demonstrating it. We covered how that record actually gets built — cryptographic chaining, hashed arguments, a chokepoint every call flows through — in auditing every agent API call. The short version: the same broker that enforces least privilege is the natural place to capture the trail, because every call already passes through it.

The business case: governance you can hand to an auditor, not just describe to one

Put the three pieces together — a proper handshake that never exposes a standing secret, resource-level scoping that respects data ownership, and a tamper-evident record of every call — and you get something a compliance program can actually use instead of merely aspire to.

This is precisely the gap Fullmakt is built to close. As a credential broker for AI agents, Fullmakt sits in the path of every agent-to-API call, not just at the login step:

• No standing secrets in the agent. Fullmakt mints short-lived, scoped credentials per task and injects the real upstream secret at the edge — the model never sees it, and rotating or revoking it never requires touching an agent’s code.
• Per-call policy, tied to data ownership. Scope is enforced by endpoint, method, resource, and rate, so an agent’s reach matches the specific data it was authorized to touch — not the broadest permission its service account happens to carry.
• A cryptographically chained audit log. Every issuance, call, and revocation is recorded and provably intact, so “what did this agent do, and was it allowed?” has a documented answer in seconds, not a research project after an incident.
• Human-in-the-loop approval gates and instant revocation. Sensitive operations can require a person’s sign-off before they execute, and cutting an agent off is a policy change, not a redeploy.
• Built on MCP and OAuth 2.1, on top of whatever identity provider you already run. Fullmakt doesn’t replace your login system — see Fullmakt vs. Auth0 for exactly where the line falls — it enforces and evidences what happens after the handshake, on every call an agent actually makes.

The commercial logic is simple: the cost of one agent gone wrong — a data exposure, a mispriced order pushed thousands of times before anyone notices, an auditor’s question you can’t answer — dwarfs the cost of a broker sitting in the call path from day one. And the same infrastructure that prevents the incident is what produces the evidence regulators and customers are increasingly asking for; we’ve mapped that connection in detail against the EU AI Act and ISO/IEC 42001.

FAQ

What does “AI agentic gone wrong” usually look like in practice? Almost never a dramatic hack. Usually a valid, authenticated agent given a credential broader or longer-lived than the task needed, which it then used — through a bug, a prompt injection, or simple scope creep — to reach data or take an action nobody intended it to.

What is a “login handshake” for an AI agent, and how is it different from a human login? It’s the same idea — prove who you are before you get access — but the output has to be a short-lived, narrowly scoped credential rather than a long-lived session, because an agent acts unattended, at machine speed, and can be steered by content it merely reads.

Who owns the data an AI agent touches? Whoever owned it before the agent existed — a customer, a team, a tenant. Authentication proves who the agent is; it takes resource-level scoping, enforced per call, to keep the agent inside the data its specific task actually concerns.

How is a credential broker different from an identity provider? An identity provider like Auth0 answers who is this, and are they allowed to log in. A broker like Fullmakt sits after that answer, on every subsequent call: injecting the real secret, checking policy for this exact request, and recording what happened. See Fullmakt vs. Auth0 for the full comparison.

Does Fullmakt ever expose real API keys to the model? No. The model and the agent only ever hold a scoped reference. Fullmakt resolves the real upstream secret and injects it at call time, outside the model’s context entirely.

Agentic AI doesn’t fail because nobody thought about security. It fails because the handshake stops at “who are you” instead of continuing on to “what, exactly, are you allowed to do with this data, right now — and can we prove it afterward.” Build for that second question and the incident reports get a lot shorter.