We often describe AI agents as “digital employees.”
At first, that sounds like a productivity concept.
They can summarize documents, write emails, search internal knowledge, update CRM records, call APIs, or complete repetitive workflows.
But I think the more important change is not productivity.
It is authority.
A chatbot generates an answer.
A digital employee can generate an answer and then act on it.
That changes the security model completely.
Imagine an AI agent receives a simple instruction:
“Find inactive customers and clean up the CRM.”
To a human, that sounds like one task.
To the system, it could become:
Read CRM records
↓
Analyze activity
↓
Check billing data
↓
Identify inactive accounts
↓
Change account status
↓
Merge duplicates
↓
Notify sales owners
The important part is that these steps were not necessarily predefined by a developer.
The agent may decide them dynamically.
That means we are connecting something unusual:
A probabilistic reasoning system to deterministic enterprise permissions.
Traditional software usually executes logic that developers explicitly wrote.
An AI agent interprets a goal, decides what actions are useful, selects tools, and then executes them.
That is a different security problem.
The obvious response is:
“Give every agent its own identity.”
I agree.
A production agent should not quietly operate through a developer API key or a shared service account.
But identity only tells us:
Who performed the action?
It does not answer the harder question:
Was the agent actually supposed to perform that action for this task?
Suppose I ask an agent:
“Prepare a customer-risk report.”
The agent may legitimately have access to CRM data.
But does that request also authorize it to export the entire customer database to an external analytics service?
Maybe I personally have permission to do that.
Maybe the agent technically has permission too.
But that does not mean I delegated that authority for this specific task.
This is where traditional IAM starts becoming insufficient.
For agents, we need to distinguish between: What the user can do
What the user asked the agent to do
What the agent decided to do
Those three things are not equivalent.
Developers already understand least privilege.
Give a service only the permissions it needs.
But agents introduce another problem: permission composition.
An agent might have:
crm.read
storage.write
email.send
Individually, none of these permissions look especially dangerous.
Together, the agent can:
Read sensitive CRM data
↓
Write it into a file
↓
Send that file externally
So the real question is no longer just:
What permissions does this agent have?
It is:
What is the maximum effect this agent can create by combining them?
I think this will become an important part of agent security.
Because agents are very good at composing tools.
That is exactly what makes them useful.
It is also what makes their authority difficult to reason about.
Another mistake is treating instructions as controls.
For example: Never send confidential information externally.
That is useful guidance for the model.
It is not a security boundary.
If an agent has access to sensitive data and an external API, the application should enforce the boundary outside the model. The agent can propose:
Export customer data But another layer should decide whether that action is actually allowed.
Something like:
User request
↓
Agent reasoning
↓
Proposed tool call
↓
Policy check
↓
Execute / Reject / Require approval
The model can decide what it wants to do.
It should not automatically decide what it is authorized to do.
That distinction feels increasingly important.
There is another issue that traditional security tools may struggle with.
Imagine an agent reads salary.xlsx.
The file itself never leaves the company.
But the agent produces:
Highest salary: $180,000
Lowest-performing employees: Alice
Bob
Charlie
and sends that result to another system.
Technically, the original file was never exfiltrated.
But the information was.
Generative AI can summarize, extract, infer, compress, and transform sensitive data.
So protecting digital employees cannot only mean tracking files.
We increasingly need to understand information flow.
Not just:
Where did the file go?
But:
What information did the agent learn, transform, and send elsewhere?
When building agents, we often start with:
Can the agent do this?
Maybe the more important production question is:
What happens if the agent reasons incorrectly while holding this level of authority?
That leads to a much better checklist:
What identity does the agent use?
Which tools can it access?
What authority was actually delegated for this task?
Which actions require approval?
How much can it do in one workflow?
Can its actions be reversed?
Can we reconstruct exactly what happened?
Can we revoke its access immediately?
The interesting thing about digital employees is not simply that software is becoming more intelligent.
It is that software is beginning to reason while holding authority.
That combination is new.
And I suspect the long-term challenge of agentic AI will not just be model quality.
It will be designing systems where powerful agents can act without silently accumulating unlimited authority.
Because intelligence determines what an agent can figure out.
Authority determines what happens next.