Your AI Agent Just Became A Power User

Your AI assistant was useful.

It answered questions.

It summarized documents.

It searched company data.

It helped users understand what was happening.

Then somebody had an idea.

“Could we just let it fix the problem?”

And with that one sentence, your AI stopped being an assistant.

It became a production user.

Welcome back to Production.

Reading Was the Easy Part

There is a significant difference between:

“Why did this order fail?”

and:

“Fix the order.”

The first requires information.

The second requires authority.

Now the AI may need to:

• Update a database.
• Create a support ticket.
• Send an email.
• Restart a pipeline.
• Change a customer record.
• Approve a workflow.
• Call an API.
• Modify a configuration.
• Trigger another agent.

Suddenly we’re not talking about what the AI knows.

We’re talking about what the AI can do.

And that changes the architecture considerably.

Who Is the AI?

This sounds like a philosophical question.

Unfortunately, it’s an identity-management question.

When Jeannine asks, “Can you update the customer’s billing address?”

who actually updates it?

• Does the AI act as Jeannine?
• Does it use a service account?
• Does it authenticate through a service principal?
• Does the application have one giant identity shared by every user?
• Does some backend API perform the action using its own credentials?

And most importantly:

Whose permissions determine whether that action is allowed?

Those questions matter a lot more once AI can change production systems.

The Sherpa’s Notebook

I’ve worked with plenty of applications and integrations that use service accounts.

That’s normal.

• An ETL process needs an identity.
• A Fabric pipeline needs an identity.
• An application connecting to Snowflake needs an identity.
• A SQL Server job needs an identity.

The problem isn’t the existence of service accounts.

The problem is what tends to happen to them over time.

An application needs access to one thing.

So we grant it.

Then it needs another.

We grant that too.

Then somebody adds another integration.

Another database.

Another role.

Another permission.

Five years later, nobody is entirely sure what the account needs anymore.

But everyone knows one thing:

Definitely Don’t disable it.

Because something will break.

Now introduce an AI agent.

The agent receives a request from a user with limited permissions.

Behind the scenes, the agent calls an application using a service identity with significantly broader permissions.

The user couldn’t perform the action directly.

But can the agent?

That’s where things get interesting.

Authentication Is Not Authorization

We tend to blur these together.

Authentication answers: Who are you?

Authorization answers: What are you allowed to do?

Your AI architecture needs both.

Knowing that Jeannine asked the question doesn’t automatically mean the downstream system is enforcing Jeannine’s permissions.

Imagine:

Jeannine → AI Agent → Application → Service Principal → API → Production Database

The database may never see Jeannine.

It sees the application’s identity.

And that identity might have permission to do considerably more than Jeannine does.

Every authentication check can succeed.

Every API call can be authorized.

Every audit log can show a legitimate identity.

And you can still have an authorization design problem.

Sound familiar?

The Super AI Account

There is an incredibly tempting shortcut when building an agent.

Give it an account that can access everything it might need.

Call it something professional like: SVC_AI_PROD

Six months later: SVC_AI_PROD2

Eventually: SVC_AI_PROD_FINAL

And because the agent needs to perform actions across several systems, we keep adding permissions.

• CRM.
• Finance.
• Support.
• Data warehouse.
• SharePoint.
• Ticketing.
• Email.
• APIs.
• Databases.

Congratulations.

You have created: SUPER_AI_ADMIN

Nobody intended to.

Every individual permission request probably made sense.

But the cumulative result is an identity capable of operating across enormous portions of the organization.

That deserves some architectural attention.

“But The User Asked It To”

That isn’t necessarily sufficient.

Suppose Jeannine tells the AI: “Cancel that order.”

Maybe Jeannine is allowed to cancel orders under $5,000.

The AI’s service identity can cancel any order.

The order is worth $250,000.

What happens?

If authorization occurs only at the service-account level, the answer might be:

Order canceled successfully.

Technically, everything worked.

That’s the problem.

The agent needs to understand not only:

Can I perform this action?

but:

Can I perform this action on behalf of this user, under these circumstances?

Those are extremely different questions.

Acting as the User

One model is to preserve the user’s identity through the transaction.

The downstream system knows Jeannine initiated the request and evaluates what Jeannine is authorized to do.

Conceptually, that’s clean.

Jeannine can do through AI what Jeannine could do herself.

But enterprise systems aren’t always designed that way.

Some APIs expect application identities.

Some legacy databases know nothing about modern identity providers.

Some integrations use shared credentials.

Some workflows cross five different systems with five completely different authorization models.

Production architecture tends to be slightly less elegant than the diagram presented during the vendor demo.

Acting as the Application

Another model is for the agent to operate through an application or workload identity.

That’s not inherently wrong either.

Automation has worked this way forever.

But now the application has to enforce the user’s authority before performing the action.

The backend may technically be capable of deleting every customer.

That doesn’t mean everyone using the AI should be able to say: “Delete Acme Industrial.”

Somewhere in that chain, somebody has to be smart enough to say that one magic word, “No.“

Preferably before DELETE executes.

Read Permissions and Write Permissions Are Different Conversations

This is another place where AI pilots can hide complexity.

During the pilot, the AI may only read.

That’s relatively safe.

Then users love it.

So we add: Create the ticket.

Then: Update the customer.

Then: Send the email.

Then: Approve the request.

Then: Run the process.

Every new action changes the risk profile.

An agent that can search a customer record is not architecturally equivalent to an agent that can modify one.

And an agent that can modify one isn’t equivalent to an agent that can approve a $250,000 transaction.

Capability needs boundaries.

“Are You Sure?” Is Not a Security Model

Human confirmation can absolutely be valuable.

For consequential actions, asking things like, “You’re about to cancel Order 48291 for $250,000. Continue?” may be exactly what we want.

But confirmation is not authorization.

If Jeannine isn’t allowed to cancel the order, asking her twice doesn’t suddenly make it okay.

“Are you sure?”

“Yes.”

Still unauthorized.

Confirmation protects against mistakes.

Authorization protects against actions the user isn’t permitted to perform.

We need both.

AI Creates Delegation Problems

Agents introduce another interesting question:

What exactly did the human authorize?

Suppose someone says:

“Resolve the billing issue for Acme Industrial.”

That sounds reasonable.

But what does resolve mean?

• Update the billing address?
• Issue a credit?
• Regenerate an invoice?
• Email the customer?
• Change payment terms?
• Create a ticket?
• Modify the account?

The broader the instruction, the more discretion we’re giving the agent.

That’s useful.

It’s also why agent permissions shouldn’t simply be:

Can access Finance: Yes

We need boundaries around actions.

Start Thinking in Verbs

Traditional access discussions often focus on nouns.

• Customer.
• Invoice.
• Order.
• Contract.
• Database.
• Report.

Agent security needs verbs too.

• Read customer.
• Update customer.
• Create order.
• Cancel order.
• Issue credit.
• Send email.
• Approve payment.
• Restart pipeline.
• Modify security.

Those verbs don’t carry equal risk.

And the identity capable of reading something shouldn’t automatically be the identity capable of changing it.

Some Actions Need Humans

There is another temptation with agents:

If the AI can perform an action, automate it.

No.

Some actions should remain recommendations.

Some should require confirmation.

Some should require approval from another person.

Some should require multiple approvals.

Some should never be available to the agent.

That’s not a failure of AI.

That’s good system design.

The question shouldn’t be: How autonomous can we make this?

It should be: Where does autonomy actually make sense?

And Then There Are Audit Logs

Suppose the AI changes a customer’s payment terms.

Six months later, Finance asks: “Who changed this?”

The audit log says: SVC_AI_PROD

Wonderful.

That tells us almost nothing.

We need to know:

• Who requested the action?
• Which agent performed it?
• What identity executed it?
• What instructions were given?
• What data did the agent use?
• What action did it decide to take?
• Was human approval required?
• Who approved it?
• What actually changed?
• Did another agent participate?

That is no longer merely application logging.

That’s decision lineage.

We’ve talked about answer lineage.

Agents need action lineage.

The Agent Didn’t Click the Button

This is another mindset change.

With traditional applications, users click buttons.

Those buttons usually represent specific actions developers anticipated.

Submit Order

Approve Invoice

Update Customer

The developer knows what each button does.

AI changes the interface.

Now the user can type: “Take care of this.”

There is probably not a button.

The AI decides which tools to call and in what sequence.

That flexibility is the entire point.

But it means we need controls around the tools rather than relying entirely on the interface.

The agent shouldn’t be safe because nobody thought to ask it something dangerous.

It should be safe because dangerous actions are appropriately controlled.

Jeannine Will Find the Missing Use Case

Eventually Jeannine is going to ask the agent to do something nobody considered during architecture.

Not because she’s trying to break it.

Because the request makes perfect sense to her.

That’s what users do.

And if the agent discovers that its combination of tools and permissions lets it perform that action…

Jeannine didn’t fail your architecture.

Your architecture failed to consider Jeannine.

That’s why agent testing can’t consist entirely of expected workflows.

You have to test the weird ones too.

The Sherpa’s Lesson

The moment AI can take action, it becomes part of your production identity and authorization architecture.

You need to know:

• Who is asking?
• Who is acting?
• Whose permissions apply?
• What actions are allowed?
• Which actions require confirmation?
• Which require approval?
• What should never be automated?
• Can we reconstruct exactly what happened afterward?

Your AI agent isn’t just a chatbot anymore.

It is a production user.

Except it can work faster than your users.

It can operate across multiple systems.

It doesn’t get tired.

And nobody had to teach it where all the buttons are.

So before giving your AI agent another tool, don’t just ask: “Can it do this?”

Ask the much more important question: “Under whose authority?”