I think a lot of AI teams are solving the wrong control problem first.
They focus on prompts. Then they focus on approvals. Then they focus on logging.
All useful. None of that answers the question that gets ugly once the workflow touches a real system.
Who is this thing acting as?
That sounds like a technical detail until the workflow starts reading customer records, updating CRM fields, routing support cases, or pushing data into finance review. Then identity stops being cleanup and becomes the operating model.
If the workflow inherits the wrong permissions, a clean approval screen will not save you.
Identity decides the blast radius
This is the part teams tend to blur together.
"The agent can access the CRM" is not a permission model.
"The workflow uses the ops lead's account for now" is not a permission model either.
Those are temporary shortcuts that quietly turn into architecture.
Identity is what decides:
- which records the workflow can see
- which actions it can take directly
- whether it can act differently for different users
- how incident review works after a bad run
If those answers are fuzzy, the workflow may still produce useful output. It just is not controlled well enough for production.
The market signal got sharper this month
The recent enterprise product signals are not just about more capable agents. They are about who gets to publish them, what connected apps they can reach, and what kind of authority they carry into a run.
Anthropic's late-May 2026 engineering write-up put the identity problem in plain terms. One of the real design questions is whether an agent should act with its own principal identity or inherit a user's permissions. That is a serious architecture decision. It changes your review path, your audit story, and the size of the mess when the workflow behaves badly.
OpenAI's June 8, 2026 and June 11, 2026 enterprise updates point in the same direction. Shared agents gained role-based publishing controls and connected apps gained more explicit permission modes and external app access controls. That matters because the conversation is moving beyond "can the workflow connect?" toward "under what authority does it operate after it connects?"
AWS made the runtime angle clearer on June 3, 2026. Step Functions added an AgentCore-powered reasoning step with human approval before critical actions and execution history that shows input, output, token usage, and duration. That is what production thinking looks like. Identity, approval, and evidence live together.
Microsoft said the quiet part out loud on June 2, 2026. The system around the model is the product. I agree. Identity is a big part of that surrounding system.
Where the problem shows up first
This usually breaks in normal workflows, not sci-fi ones.
Take a CRM assistant. Maybe it summarizes calls, drafts follow-up tasks, and updates stage notes.
If it runs as a broad inherited user identity, it may see more accounts than it needs. It may write fields nobody expected it to touch. It may be impossible to separate workflow mistakes from real user activity during review.
Or take a finance review workflow.
Maybe it extracts invoice data, compares line items, and flags exceptions for approval.
If that workflow inherits a person's full document and accounting access just because it was easier to wire up, you have already made a governance decision. You just made it by accident.
Support routing has the same problem. So does intake processing. So does document review in regulated environments.
The pattern is simple. The more the workflow touches live systems, the less acceptable "it uses whoever set it up" becomes.
Approval without identity is mostly theater
I am not against approval gates. Most teams need them.
I just do not think they work well when identity is still muddy.
A reviewer needs to know what they are approving.
Not just the output. The authority behind the output.
If the workflow can read too much, write too broadly, or move across systems under a borrowed identity, the approval step is compensating for a control gap it cannot really fix.
That is why a single "approve" button often feels safer than it is.
The right sequence is:
- define the workflow identity
- scope what that identity can read and change
- separate read, draft, route, and write actions
- place approval before the risky action
- keep enough evidence to reconstruct the run later
Skip the first two and the rest gets shaky fast.
A cleaner way to decide identity
I would keep the decision blunt.
If the workflow is repeatable, touches shared business systems, and does not need a different authority model for every human operator, start by asking whether it should have its own scoped service identity.
That usually gives you a cleaner review trail and tighter boundaries.
If the workflow truly needs user-specific context or must act inside a user's narrow rights, then inherited identity can make sense. But it should still be explicit, constrained, and observable. Not a convenience choice buried in setup.
The important thing is not that one model always wins.
It is that the team can explain why the workflow uses that identity, what systems it can reach, and how they would investigate a bad run.
What buyers actually want to hear
I do not think most buyers want a lecture on IAM theory.
They want to know that the workflow will not quietly get wider access than intended.
They want to know a reviewer can see what happened.
They want to know a service built for support routing is not accidentally operating like a roaming admin.
That is why identity belongs earlier in the sales and discovery process now. Once an AI workflow touches the CRM, ticket queue, finance stack, or internal docs, the buyer is already asking a version of the same question:
Whose authority is this running under?
If the answer is vague, the deal slows down. Usually for good reason.
A practical production standard
Here is the standard I would use.
Before an AI workflow touches a live business system, the team should be able to answer four questions clearly:
- what identity the workflow uses
- what exact scope that identity has
- which actions are automatic versus approval-gated
- what evidence survives after each meaningful run
If you are working through connector scope and approval placement too, read Your Connector Approval Is Not Your Runtime Safety Model. If the immediate failure mode in your environment is still shared credentials, read Agents Need Identities, Not Shared Logins.
If you cannot answer those cleanly, the workflow may still be a useful prototype.
It is not ready to act like infrastructure.
If your team is stuck between a promising AI workflow and a permission model you can actually defend, book a discovery call:
https://calendly.com/martintechlabs/discovery
Sources
- Anthropic: How we contain Claude across products
- OpenAI Help Center: ChatGPT Enterprise & Edu release notes
- AWS: AWS Step Functions adds AgentCore-powered agentic reasoning step
- Microsoft: AI alone won't change your business. The system running it will.
FAQ
Why does AI workflow identity matter in production?
Because identity decides what the workflow can read, what it can change, and whose permissions it is using when something goes wrong. If that part is vague, approval steps and audit logs will not close the control gap.
Should an AI workflow act as a user or a service account?
It depends on the workflow, but the choice should be explicit. Many production teams use a scoped service identity for repeatable automation and reserve direct user identity for tightly bounded tasks that need user-specific context.
What goes wrong when agent identity is left implicit?
Teams end up with workflows that inherit broad access, write into live systems without clear ownership, and create messy incident reviews because nobody can say which permissions were actually in play.
Do approval gates solve AI permission problems by themselves?
No. Approval helps only when the workflow identity, scope, and action boundaries are already defined. Otherwise the reviewer is approving work from a system they do not fully understand.