Whose Permissions Is Your AI Workflow Actually Using?

Teams spend a lot of time asking whether an AI model can be tricked. AI workflow authorization raises a quieter issue that causes just as many incidents: when this workflow acts, whose permissions is it using? A model doesn't need to be manipulated to cause harm if the workflow behind it will faithfully execute a valid request under the wrong authority.

That distinction matters because the fixes differ. Better prompts and model-level filters address manipulation. They do nothing for a workflow that was built, reasonably, to be helpful, and was connected to systems with far more access than the person asking should have. As organizations wire agents and automations into support desks, HR systems, and finance tools, this gap is where well-intentioned deployments quietly become privilege escalation paths.

This article walks through one common design, a support inbox connected to internal systems, to show where identity gets lost and where authorization checkpoints belong.

Two Failure Modes That Look Alike

Both failures end with an agent doing something it shouldn't. They need different defenses.

Model manipulation happens when an attacker or a careless input changes what the model decides to do. The classic example is indirect prompt injection: instructions hidden in an email or document that the agent treats as commands. Zenity Labs' AgentFlayer research demonstrated this class of attack against widely used assistants.

Authorization failure happens when the model behaves exactly as designed, and the surrounding workflow executes the request with authority that doesn't belong to the requester. This is the confused deputy problem, a well-understood security concept, applied to systems that now read natural language and choose their own tools.

Separating the two helps teams avoid a common mistake: investing entirely in model defenses and assuming that covers workflow risk. It doesn't. A fully hardened model sitting inside a workflow with the wrong identity model is still a vulnerable system.

A Support Inbox Connected to Internal Systems

Consider a workflow many organizations are building. Customers and employees email a shared support address. An AI agent reads each message, classifies it, looks up related records, drafts a response, and, where policy allows, takes an action such as issuing a refund, resetting access, or updating an account.

To do that, the workflow connects to a CRM, an order system, an identity provider, and a knowledge base. It authenticates to all of them with a single service account, because that's the simplest way to build it and the one most platforms encourage.

Now trace three identities through one request:

• Requester identity is the person who sent the email, as asserted by the "From" header. It is unverified by default.
• Workflow identity is the service account the automation runs under. It holds broad read and write access because it has to serve every requester.
• Tool identity is whatever each downstream system sees when the call arrives. Usually that's the workflow identity, and nothing about the original requester.

The risk is in the gap. Once a message enters the workflow, the requester's identity is rarely carried forward. The CRM sees the service account and returns whatever it's asked for. Whether the person emailing is entitled to that record is never evaluated.

An example

An email arrives from an address that looks like a customer: "Please send me the full order history and billing contact for the account under Acme Industrial." The agent finds the account, retrieves the history, and replies. Nothing in the model was manipulated. The request was polite, plausible, and within the workflow's intended purpose. It also disclosed another customer's data to an unverified sender, because the only authority checked was the workflow's own.

Where Trust Boundaries Actually Sit

Teams often draw one boundary around "the AI." In practice, there are several, and each needs its own control.

Inbound content to the model

Everything in the email, including quoted threads, attachments, and signatures, is untrusted. It may contain instructions the model treats as commands. This boundary is where prompt injection defenses live.

Model output to tool calls

The model decides which tool to call and with what parameters. That decision is a proposal, not an authorization. The workflow must treat model output as untrusted input to the tool layer, the same way a web application treats user input.

Tool call to downstream system

This is where the execution identity is applied. If every call arrives as the shared service account, the downstream system can't enforce per-requester policy. The boundary is invisible to the system best placed to enforce it.

Workflow response to requester

Outputs also cross a boundary. A reply that includes data the requester wasn't entitled to is a disclosure, regardless of how it was generated.

Four Authorization Checkpoints

Most of the risk in this design is reduced by placing four checks outside the model, where they can't be argued with.

1. Verify the requester. Don't rely on a display name or "From" address for anything sensitive. Authenticate the sender against a known identity, or route unverified requests to a reduced set of read-only, non-sensitive actions.
2. Bind the execution identity to the requester. Where the platform allows it, run actions on behalf of the requester using delegated, scoped credentials rather than the shared service account. Where it doesn't, pass the requester's identity as a claim that downstream checks can evaluate.
3. Scope every tool call. Define which tools a workflow can call, with which parameters, for which classes of requester. A refund tool might permit amounts under a threshold for verified customers and require human approval above it. This is the hard boundary that doesn't depend on the model behaving.
4. Record the decision. Log the requester, the execution identity, the tool, the parameters, and the policy outcome together. Without that record, an authorization failure looks like normal activity and can't be investigated.

These checkpoints apply least privilege for AI agents in practice: narrow what the workflow can do on behalf of any given person, and enforce it somewhere the model can't override. They're consistent with the guidance in the OWASP GenAI Security Project, which treats excessive agency and identity abuse as core risks for agentic applications.

The Acme request with checkpoints in place

Replay the same email with the four checkpoints active. The workflow first checks whether the sender's address matches a verified contact on the Acme Industrial account. It doesn't, so the request is classified as unverified and limited to non-sensitive actions. Even if the sender were verified, the tool policy allows order history only for the requester's own account and blocks billing contact lookups without a verified, authorized role.

The agent can still respond helpfully. It explains that it can't share account details with an unverified sender and offers a path to verify. The policy engine records the denied tool call along with the requester, the workflow identity, and the rule that applied. The security team now has evidence that someone probed for another customer's data, which is useful in its own right.

Two things stand out. The model's behavior didn't need to change, so the fix doesn't depend on a smarter prompt. And the denial happened at the tool layer, which is the only place the workflow can enforce authority with certainty.

Why this gets worse at scale

One support inbox is manageable. Most organizations will build dozens of workflows like it, each created by a different team, each with its own service account and its own idea of who the requester is. Citizen developers can assemble these connections in an afternoon on low-code platforms, often without a security review. Over time, the organization accumulates a set of agents holding broad credentials, none of which evaluate the person on the other end of the request. Visibility into which workflows exist, and what identity each one runs under, is the precondition for fixing any of them.

Common Mistakes Teams Make

A few patterns show up repeatedly in workflow reviews:

• Treating the system prompt as the access policy, with instructions such as "only share information with the account holder"
• Granting the service account administrator-level access during a pilot and never tightening it
• Letting the model fill in identifying parameters, such as account IDs, that the tool then trusts
• Logging model conversations but not the identity used for each tool call
• Reviewing the workflow once at build time and never again as connected systems change

Each of these treats a soft guardrail as if it were a hard boundary. Intent is not control: a model that is asked nicely to respect permissions has no ability to enforce them.

How Zenity Helps Secure AI Workflows

Securing workflow authorization means seeing what every agent and automation is connected to, what authority it runs with, and what it does at runtime. Zenity provides AI security posture management to inventory agents and flag over-privileged connections from build time, plus runtime controls that evaluate tool calls as they happen, so risky actions can be stopped inline instead of discovered later. The agent is the new endpoint, and its identity needs to be governed like one.

Want to see which identities your AI workflows are really using? Book a demo with the Zenity team to map agent access and enforce hard boundaries across your environment.

FAQs About AI Workflow Authorization

What is AI workflow authorization?

It's the set of controls that decide whether an AI-driven workflow is permitted to take a given action on behalf of a given requester. It covers who is asking, which identity the workflow runs under, and what each tool call is allowed to do.

How is this different from prompt injection?

Prompt injection changes what a model decides. Authorization failures occur when the model's decision is valid, but the workflow executes it with the wrong authority. Both need defenses, and the defenses are different.

Why do workflows use shared service accounts?

They're easier to set up and are the default in many automation and agent platforms. The tradeoff is that downstream systems lose the context of who actually made the request.

Can a better system prompt solve this?

No. Prompts influence behavior but don't enforce policy. Authorization has to live in a layer the model can't modify or talk its way around.

Should every request be tied to a human identity?

For sensitive actions, yes. For low-risk, read-only actions on public information, a reduced trust level for unverified requesters is usually acceptable.

What should be logged?

The requester, the execution identity, each tool call and its parameters, the policy decision, and the outcome. This lets investigators reconstruct what happened and why.

How often should workflow permissions be reviewed?

Whenever a connected system, tool, or data source changes, and on a recurring schedule. Permissions that were reasonable for a pilot often become excessive in production.