AI Agents Change the Security Model

WEBVTT
00:00:02.799 --> 00:00:11.919
For most of the history of Enterprise IT, we've spent an extraordinary amount of time deciding what humans are allowed to do, which is impressive because we're still not.
00:00:12.720 --> 00:00:14.640
Let's start with terminology.
00:00:14.880 --> 00:00:25.199
Because as usual, the technology industry has managed to create several slightly different definitions for something while simultaneously using the same word for all of them.
00:00:25.440 --> 00:00:28.160
An AI assistant generally helps a person.
00:00:28.480 --> 00:00:31.600
You ask a question, it gives you an answer.
00:00:31.839 --> 00:00:35.679
You ask it to draft an email, it drafts the email.
00:00:36.000 --> 00:00:39.920
You ask it to summarize a meeting, it summarizes the meeting.
00:00:40.159 --> 00:00:44.640
The human remains very obviously in control of what happens next.
00:00:44.880 --> 00:00:52.719
An AI agent goes further, an agent can be given a goal and potentially work through multiple steps to achieve it.
00:00:52.960 --> 00:01:03.359
It may retrieve information, reason about what it finds, choose an action, use a tool, evaluate the result, and decide what to do next.
00:01:03.840 --> 00:01:10.079
That doesn't necessarily mean some science fiction autonomous system wandering freely around your network.
00:01:10.319 --> 00:01:11.760
It could be quite simple.
00:01:12.079 --> 00:01:14.480
Imagine an IT support agent.
00:01:14.719 --> 00:01:18.319
An employee says, I can't access the finance application.
00:01:18.640 --> 00:01:33.840
The agent checks the user's account, looks at recent authentication activity, checks whether they're entitled to the application, searches the knowledge base, maybe identifies the problem, then creates or updates the service ticket.
00:01:34.079 --> 00:01:35.359
That's useful.
00:01:35.840 --> 00:01:38.239
Now allow it to reset the account.
00:01:38.480 --> 00:01:39.519
More useful.
00:01:39.760 --> 00:01:42.000
Allow it to modify a group membership.
00:01:42.480 --> 00:01:43.840
Even more useful.
00:01:44.239 --> 00:01:47.120
Allow it to approve the access request itself.
00:01:47.359 --> 00:01:49.280
Now we've changed something important.
00:01:49.439 --> 00:01:52.319
We haven't simply given the AI more intelligence.
00:01:52.480 --> 00:01:54.079
We've given it more authority.
00:01:54.719 --> 00:01:58.719
I think there are three useful ways to think about AI in the enterprise.
00:01:59.040 --> 00:02:00.400
AI advises.
00:02:00.640 --> 00:02:02.079
AI assists.
00:02:02.560 --> 00:02:03.760
AI acts.
00:02:03.920 --> 00:02:10.159
If an AI system tells me this user account looks suspicious, I recommend disabling it.
00:02:10.400 --> 00:02:12.159
The AI is advising me.
00:02:12.319 --> 00:02:13.759
I still make the decision.
00:02:14.000 --> 00:02:21.360
If the AI prepares the action and says I have identified the account and prepared the disable operation, would you like me to proceed?
00:02:21.599 --> 00:02:25.280
Now it's assisting me, but I still approve the action.
00:02:25.520 --> 00:02:32.800
If the AI identifies the account, decides the activity is suspicious, and disables it automatically.
00:02:33.439 --> 00:02:35.680
The AI is acting.
00:02:35.919 --> 00:02:40.800
The intelligence may be very similar in all three scenarios, but the risk isn't.
00:02:41.120 --> 00:02:45.120
Because in the third example, we've delegated authority to software.
00:02:45.360 --> 00:02:49.599
That's why I think autonomy is sometimes described in the wrong way.
00:02:49.840 --> 00:02:51.680
We talk about it as if it's a feature.
00:02:51.759 --> 00:02:53.759
How autonomous is the agent?
00:02:54.080 --> 00:03:02.240
But from a security and governance perspective, I think the better question is: how much authority are we prepared to delegate to software?
00:03:02.560 --> 00:03:05.039
That framing changes the conversation.
00:03:05.520 --> 00:03:09.120
Because organizations already understand delegated authority.
00:03:09.360 --> 00:03:17.919
We delegate authority to employees, managers, administrators, applications, service accounts, third parties.
00:03:18.479 --> 00:03:21.680
And every time we do, we put boundaries around it.
00:03:21.919 --> 00:03:23.360
At least we're supposed to.
00:03:23.680 --> 00:03:26.560
AI agents don't make that principle obsolete.
00:03:26.719 --> 00:03:28.240
They make it more important.
00:03:28.800 --> 00:03:34.000
In episode three, we talked about identity effectively becoming part of the AI query.
00:03:34.319 --> 00:03:39.599
Your identity helps determine what information an enterprise AI system can retrieve.
00:03:39.840 --> 00:03:42.960
With agents, identity becomes even more important.
00:03:43.360 --> 00:03:49.360
Because now identity doesn't just determine what the AI can know, it may determine what the AI can do.
00:03:49.680 --> 00:03:55.439
Every agent that interacts with enterprise systems needs some way of being recognized.
00:03:55.680 --> 00:03:59.199
It may operate using the identity of the person invoking it.
00:03:59.439 --> 00:04:10.080
It may have its own application identity, it may use a service principal, a service account, a workload identity, or some combination depending on what it's doing.
00:04:10.240 --> 00:04:11.919
Those distinctions matter.
00:04:12.159 --> 00:04:19.600
Because when the agent calls an API or changes something in another system, that system needs to answer a very basic question.
00:04:19.920 --> 00:04:21.279
Who is asking?
00:04:21.519 --> 00:04:22.720
And then another one.
00:04:22.959 --> 00:04:24.399
Are they allowed to do this?
00:04:24.560 --> 00:04:27.120
This is authentication and authorization.
00:04:27.360 --> 00:04:29.439
Very familiar security concepts.
00:04:29.600 --> 00:04:36.959
But AI agents make them interesting again because we're creating potentially enormous numbers of non-human actors.
00:04:37.279 --> 00:04:40.879
And those actors may be operating across multiple applications.
00:04:41.279 --> 00:04:47.439
So before we get carried away discussing how intelligent the agent is, I'd ask something much more mundane.
00:04:47.839 --> 00:04:49.920
What identity does it use?
00:04:50.240 --> 00:04:54.879
If nobody can answer that clearly, I'm probably not ready for the demo yet.
00:04:55.600 --> 00:05:01.120
Let's say an agent is helping me perform a task, whose permissions should it use?
00:05:01.600 --> 00:05:05.040
Mine, its own, some combination?
00:05:05.600 --> 00:05:11.680
There are legitimate architectures for each approach, but the security consequences are different.
00:05:11.920 --> 00:05:17.680
If the agent acts entirely as me, then ideally it should be constrained by my permissions.
00:05:18.079 --> 00:05:19.519
That's intuitive.
00:05:19.759 --> 00:05:26.240
If I can't access the payroll system, my AI agent shouldn't suddenly develop a keen interest in salaries.
00:05:26.480 --> 00:05:30.000
But what if the agent needs capabilities I don't normally have?
00:05:30.319 --> 00:05:32.720
Perhaps it's an IT support agent.
00:05:33.040 --> 00:05:39.040
It may need to perform specific administrative actions on behalf of employees.
00:05:39.279 --> 00:05:50.399
Now we may give the agent its own permissions, that's where things become more interesting, because the agent might have authority that the person interacting with it doesn't have.
00:05:50.639 --> 00:05:57.360
So we need to make sure the user can't manipulate the agent into exercising that authority inappropriately.
00:05:57.920 --> 00:06:00.639
This is not a completely new security problem.
00:06:01.040 --> 00:06:04.720
Applications have been acting on behalf of users for decades.
00:06:05.279 --> 00:06:07.600
But AI changes the interface.
00:06:07.759 --> 00:06:18.480
Instead of selecting from predefined buttons and workflows, the user can communicate with the application in natural language, and the system itself may decide which tool to invoke.
00:06:18.639 --> 00:06:22.160
That flexibility is what makes agents powerful.
00:06:22.399 --> 00:06:25.839
It's also what makes authorization design so important.
00:06:26.399 --> 00:06:30.639
Natural language should not become a shortcut around least privilege.
00:06:30.959 --> 00:06:34.079
This is where I'd separate capability from authority.
00:06:34.319 --> 00:06:38.720
An AI model may be capable of deciding that a purchase order should be approved.
00:06:38.959 --> 00:06:42.000
That doesn't mean it should have the authority to approve one.
00:06:42.240 --> 00:06:46.399
It may be capable of determining that an employee should receive access to a system.
00:06:46.639 --> 00:06:48.399
That doesn't mean it should grant the access.
00:06:48.560 --> 00:06:50.959
It may be capable of writing a payment instruction.
00:06:51.120 --> 00:06:53.600
Please don't immediately give it the bank account.
00:06:53.920 --> 00:06:55.920
Capability is a technical question.
00:06:56.160 --> 00:06:58.800
Authority is a governance question.
00:06:59.199 --> 00:07:02.480
And organizations need to be very deliberate about the difference.
00:07:02.720 --> 00:07:06.399
One useful approach is to think about the consequence of the action.
00:07:06.720 --> 00:07:10.319
Low consequence actions may be appropriate for greater autonomy.
00:07:10.560 --> 00:07:17.360
Creating a draft response, categorizing a ticket, scheduling a meeting, updating a low risk record.
00:07:17.680 --> 00:07:21.199
As consequences increase, perhaps we require approval.
00:07:21.439 --> 00:07:30.160
Changing permissions, making financial commitments, deleting data, modifying production systems, communicating externally.
00:07:30.319 --> 00:07:34.480
The question isn't whether the AI can technically do these things.
00:07:34.800 --> 00:07:36.000
It probably can.
00:07:36.240 --> 00:07:39.360
The question is whether we've deliberately decided that it should.
00:07:39.519 --> 00:07:44.639
That's why I think one of the most important controls for a gentic AI isn't particularly exotic.
00:07:44.800 --> 00:07:47.519
It's a clear definition of delegated authority.
00:07:47.680 --> 00:07:49.040
What can the agent decide?
00:07:49.120 --> 00:07:50.160
What can it recommend?
00:07:50.319 --> 00:07:51.519
What can it execute?
00:07:51.680 --> 00:07:54.160
And when does a human have to become involved?
00:07:54.480 --> 00:07:59.279
Enterprise IT already has a long and distinguished history of service accounts.
00:07:59.519 --> 00:08:00.959
You know the ones.
00:08:01.360 --> 00:08:10.879
Created for something terribly important in 2014, owned by somebody who left in 2018, running a process nobody fully understands.
00:08:11.120 --> 00:08:16.800
With a password, nobody wants to change because we're not entirely sure what will stop working.
00:08:16.959 --> 00:08:22.560
So naturally, we're now going to add intelligent, autonomous software to the mix.
00:08:22.800 --> 00:08:24.639
What could possibly go wrong?
00:08:24.879 --> 00:08:28.240
The lesson from service accounts is actually very relevant.
00:08:28.560 --> 00:08:30.959
Non-human identities need ownership.
00:08:31.120 --> 00:08:32.720
They need lifecycle management.
00:08:32.879 --> 00:08:37.440
They need appropriate permissions, they need credentials that are protected and rotated.
00:08:37.759 --> 00:08:41.279
They need monitoring, and eventually they need to be retired.
00:08:41.440 --> 00:08:42.879
Agents are no different.
00:08:43.120 --> 00:08:48.480
If anything, they're more important because the number of machine identities could grow very quickly.
00:08:48.720 --> 00:09:02.799
Imagine every department creating agents, finance agents, HR agents, sales agents, procurement agents, security agents, personal productivity agents, then agents creating or invoking other agents.
00:09:03.519 --> 00:09:10.559
Suddenly identity governance isn't just about employees and contractors, it's about a growing workforce of digital actors.
00:09:10.799 --> 00:09:16.399
If we're not careful, we could recreate 20 years of service account debt in about 18 months.
00:09:16.639 --> 00:09:19.279
Technology does seem to be getting faster.
00:09:19.679 --> 00:09:22.559
Agents become useful when we give them tools.
00:09:22.799 --> 00:09:25.679
A tool might allow the agent to search SharePoint.
00:09:26.159 --> 00:09:27.840
Query Salesforce.
00:09:28.159 --> 00:09:29.840
Create a ServiceNow ticket.
00:09:30.000 --> 00:09:31.039
Send an email.
00:09:31.200 --> 00:09:32.799
Run a database query.
00:09:33.039 --> 00:09:34.799
Call a cloud API.
00:09:35.039 --> 00:09:36.639
Modify a configuration.
00:09:36.879 --> 00:09:40.480
The more tools we add, the more useful the agent becomes.
00:09:40.720 --> 00:09:42.559
But there's an important principle here.
00:09:42.720 --> 00:09:48.399
Every time you give the agent another tool, you're not just adding a feature, you're adding authority.
00:09:48.639 --> 00:09:51.120
A chatbot with no tools can say something wrong.
00:09:51.279 --> 00:09:52.639
That's obviously a problem.
00:09:52.799 --> 00:09:57.679
But an agent with access to enterprise systems can potentially do something wrong.
00:09:57.840 --> 00:09:59.919
That's a different level of consequence.
00:10:00.080 --> 00:10:06.879
So tool access needs the same scrutiny would apply to permissions for a human administrator or application.
00:10:07.120 --> 00:10:13.360
Does the agent need read access, write access, delete access, administrative access?
00:10:13.679 --> 00:10:16.399
Can we constrain which operations it can perform?
00:10:16.639 --> 00:10:19.120
Can we limit which records it can modify?
00:10:19.360 --> 00:10:22.399
Can we restrict transactions above a certain value?
00:10:22.639 --> 00:10:25.600
Can we require approval for higher risk actions?
00:10:25.840 --> 00:10:28.960
And critically, can we revoke the tool?
00:10:29.120 --> 00:10:34.480
Because the easiest way to stop an agent from doing something may simply be to remove its ability to do it.
00:10:34.720 --> 00:10:35.919
That sounds obvious.
00:10:36.080 --> 00:10:38.639
Security occasionally benefits from obvious.
00:10:39.039 --> 00:10:41.600
We also need to accept something fairly basic.
00:10:41.840 --> 00:10:43.519
Agents will make mistakes.
00:10:43.759 --> 00:10:44.720
Humans do.
00:10:44.960 --> 00:10:46.000
Software does.
00:10:46.240 --> 00:10:47.600
AI certainly does.
00:10:47.840 --> 00:10:51.120
The question isn't whether an agent will ever make a bad decision.
00:10:51.279 --> 00:10:54.559
The question is what happens when it does.
00:10:54.799 --> 00:10:58.159
Suppose an agent incorrectly closes a support ticket.
00:10:58.480 --> 00:10:59.279
Annoying.
00:10:59.519 --> 00:11:01.919
Suppose it sends the wrong internal email.
00:11:02.159 --> 00:11:03.279
More annoying.
00:11:03.519 --> 00:11:06.320
Suppose it removes access from the wrong employee.
00:11:06.639 --> 00:11:08.240
Potentially disruptive.
00:11:08.559 --> 00:11:11.360
Suppose it modifies a production environment.
00:11:11.600 --> 00:11:14.320
Now the meeting invitations start appearing.
00:11:14.559 --> 00:11:16.000
The consequence matters.
00:11:16.159 --> 00:11:19.039
This is why autonomy should be proportional to risk.
00:11:19.200 --> 00:11:25.039
For some actions we may be perfectly comfortable allowing the agent to operate automatically.
00:11:25.360 --> 00:11:27.919
For others we may want confirmation.
00:11:28.159 --> 00:11:34.559
For higher risk actions we may require formal approval or prohibit autonomous execution entirely.
00:11:34.799 --> 00:11:36.399
And we need reversibility.
00:11:36.639 --> 00:11:38.639
Can we undo what the agent did?
00:11:38.960 --> 00:11:40.879
Can we restore the previous state?
00:11:41.120 --> 00:11:43.360
Can we identify every action it took?
00:11:43.679 --> 00:11:45.440
Can we stop it while it's running?
00:11:45.679 --> 00:11:51.279
One of the least glamorous but most important questions in agent security is where's the off switch?
00:11:51.519 --> 00:11:54.000
Not philosophically, literally.
00:11:54.240 --> 00:11:55.759
How do we stop this thing?
00:11:56.559 --> 00:12:00.879
Prompt injection is already a significant AI security concern.
00:12:01.679 --> 00:12:06.960
At a simple level, the AI encounters instructions that attempt to change its behavior.
00:12:07.200 --> 00:12:10.559
Sometimes those instructions come directly from the user.
00:12:10.799 --> 00:12:14.240
Sometimes they're hidden inside content the AI is processing.
00:12:14.480 --> 00:12:18.720
A document, a website, an email, a support ticket.
00:12:19.039 --> 00:12:26.159
Now think about the difference between an AI system that can only generate text and an agent that can take actions.
00:12:26.399 --> 00:12:30.559
If I manipulate a chatbot into producing a strange answer, that's a problem.
00:12:30.720 --> 00:12:39.120
If I manipulate an agent into sending information somewhere, changing a record or invoking a privileged tool, the consequence can be considerably greater.
00:12:39.360 --> 00:12:42.240
This is sometimes called indirect prompt injection.
00:12:42.480 --> 00:12:47.360
The malicious instruction may be sitting inside data the agent has been asked to process.
00:12:47.840 --> 00:12:55.600
Imagine an agent reading an external document that contains instructions intended for the AI rather than the human reader.
00:12:55.840 --> 00:13:03.279
The agent has to distinguish between this is information I should analyze, and this is an instruction I should follow.
00:13:03.600 --> 00:13:06.480
Humans struggle with suspicious emails.
00:13:06.639 --> 00:13:09.519
We've now created software that reads all of them.
00:13:09.840 --> 00:13:10.639
Progress.
00:13:10.879 --> 00:13:15.519
This is why agent security can't rely entirely on telling the model to behave itself.
00:13:15.679 --> 00:13:28.159
We need controls around the model, strong authorization, tool restrictions, data boundaries, validation, monitoring, approval for consequential actions.
00:13:28.399 --> 00:13:30.960
The model is part of the security architecture.
00:13:31.120 --> 00:13:33.519
It shouldn't be the entire security architecture.
00:13:34.399 --> 00:13:40.000
One of the most common responses to agent risk is we'll keep a human in the loop.
00:13:40.320 --> 00:13:40.960
Good.
00:13:41.200 --> 00:13:45.759
I'm generally in favor of humans, but we need to be slightly more specific.
00:13:46.000 --> 00:13:49.279
Which human and what exactly are they approving?
00:13:49.679 --> 00:13:59.120
If the agent produces a 200-page analysis and then asks somebody, approve, we haven't necessarily created meaningful oversight.
00:13:59.600 --> 00:14:08.399
We've created a button, and humans are remarkably good at clicking buttons, especially when the button appears 17 times before lunch.
00:14:08.720 --> 00:14:14.480
Approval fatigue is real, so human in the loop controls need to be designed carefully.
00:14:14.879 --> 00:14:17.840
The person approving the action needs enough context.
00:14:18.000 --> 00:14:26.080
They need appropriate authority, they need to understand the consequence, and the approval should occur at the point where it actually matters.
00:14:26.399 --> 00:14:31.120
We also shouldn't require human approval for every trivial action.
00:14:31.279 --> 00:14:39.919
If every agent interaction generates an approval request, people will either stop using the agent or start approving everything automatically.
00:14:40.080 --> 00:14:45.519
Neither is particularly useful, so again, risk should determine the control.
00:14:45.919 --> 00:14:48.559
Low risk action, automate it.
00:14:48.799 --> 00:14:51.440
Moderate consequence, perhaps confirmation.
00:14:51.840 --> 00:14:55.120
High consequence require explicit authorization.
00:14:55.360 --> 00:14:56.879
Very high consequence?
00:14:57.120 --> 00:15:00.399
Maybe the agent shouldn't be able to perform it at all.
00:15:00.639 --> 00:15:06.159
Human oversight is valuable, but only if the human is actually overseeing something.
00:15:06.480 --> 00:15:13.279
If an employee makes a significant change in an enterprise system, we generally want to know who did it.
00:15:13.759 --> 00:15:15.120
Agents shouldn't be different.
00:15:15.279 --> 00:15:17.759
In fact, we probably need more context.
00:15:18.000 --> 00:15:19.519
Who invoked the agent?
00:15:19.679 --> 00:15:21.600
Which agent was involved?
00:15:21.840 --> 00:15:23.840
What identity did it use?
00:15:24.399 --> 00:15:26.559
What information did it retrieve?
00:15:26.799 --> 00:15:28.399
What decision did it make?
00:15:28.639 --> 00:15:30.159
Which tool did it call?
00:15:30.399 --> 00:15:31.759
What action occurred?
00:15:31.919 --> 00:15:33.679
Was human approval involved?
00:15:33.919 --> 00:15:35.360
What happened afterwards?
00:15:35.600 --> 00:15:40.960
That's a lot more interesting than a log entry saying API call successful.
00:15:41.360 --> 00:15:46.720
From a security perspective, agent observability is going to matter enormously.
00:15:46.960 --> 00:15:52.320
Because when something goes wrong, somebody will ask, why did the AI do that?
00:15:52.639 --> 00:15:57.360
And I'd strongly prefer the answer not to be we're not entirely sure.
00:15:57.600 --> 00:16:01.440
That's rarely a satisfying sentence in front of an audit committee.
00:16:01.759 --> 00:16:04.080
Logging also helps with normal operations.
00:16:04.320 --> 00:16:21.919
We can see whether agents are behaving as expected, whether permissions are being used appropriately, whether particular actions are happening more frequently than anticipated, whether users are attempting unusual things, and whether the agent is repeatedly getting something wrong.
00:16:22.240 --> 00:16:27.519
Agents need accountability, and accountability requires evidence.
00:16:27.759 --> 00:16:37.600
If an autonomous system can make decisions, but we can't reconstruct those decisions afterwards, we've created a governance problem, possibly a very efficient one.
00:16:38.000 --> 00:16:41.519
There's another old control that becomes surprisingly relevant.
00:16:41.840 --> 00:16:43.440
Separation of duties.
00:16:44.240 --> 00:16:50.399
We use separation of duties because we generally don't want one person controlling an entire high-risk process.
00:16:50.639 --> 00:16:54.480
The person requesting a payment may not be the person approving it.
00:16:54.720 --> 00:16:58.639
The person requesting privileged access may not be the person granting it.
00:16:58.879 --> 00:17:03.360
The developer may not be able to push whatever they like directly into production.
00:17:03.840 --> 00:17:06.160
Well, that's the theory.
00:17:06.400 --> 00:17:09.759
Agents shouldn't automatically be exempt from those principles.
00:17:09.920 --> 00:17:17.119
Imagine an AI agent that can create a vendor, approve the vendor, create a payment, and authorize the payment.
00:17:17.279 --> 00:17:18.640
That's not efficiency.
00:17:18.799 --> 00:17:22.240
That's an internal audit finding with excellent branding.
00:17:22.640 --> 00:17:28.319
So when agents participate in business processes, we need to understand the role they're performing.
00:17:28.799 --> 00:17:33.519
Is the agent the requester, the analyst, the approver, the executor?
00:17:33.759 --> 00:17:36.640
Can the same agent perform conflicting roles?
00:17:36.960 --> 00:17:42.480
Can two agents collude unintentionally because they're using the same underlying authority?
00:17:42.720 --> 00:17:48.799
Do human separation of duty controls still apply when one of the participants isn't human?
00:17:49.279 --> 00:17:54.240
These are exactly the sorts of questions governance teams should start asking now.
00:17:54.720 --> 00:17:57.039
AI may change who performs the work.
00:17:57.119 --> 00:18:00.319
It doesn't automatically change why the control existed.
00:18:00.640 --> 00:18:05.200
There's a temptation when building agents to give them broad permissions because it's easier.
00:18:05.440 --> 00:18:11.519
The developer wants the agent to perform ten different tasks, so we give it access to everything it might need.
00:18:11.759 --> 00:18:12.799
The demo works.
00:18:13.039 --> 00:18:14.319
Everyone is delighted.
00:18:14.559 --> 00:18:23.440
Then the prototype becomes production, which in enterprise technology can happen with remarkable speed when somebody important likes the demo.
00:18:24.079 --> 00:18:26.240
This is where least privilege matters.
00:18:26.400 --> 00:18:31.279
An agent should have the minimum authority necessary to perform its intended function.
00:18:31.440 --> 00:18:34.640
And ideally, that authority should be contextual.
00:18:34.880 --> 00:18:48.319
Perhaps it can perform an action only for the user who invoked it, only within a specific system, only for a certain transaction type, only below a particular threshold, only during a defined workflow.
00:18:48.559 --> 00:18:52.160
And perhaps some permissions should exist only when needed.
00:18:52.559 --> 00:18:56.240
Just in time access is particularly interesting here.
00:18:56.480 --> 00:19:04.880
Instead of giving the agent standing privilege forever, allow it to acquire specific authority for a specific task under defined conditions.
00:19:05.119 --> 00:19:13.279
That's much healthier than creating another highly privileged identity and hoping everyone remembers why it exists five years from now.
00:19:13.519 --> 00:19:16.160
Because we already know how that story ends.
00:19:16.319 --> 00:19:21.359
Usually with somebody in cybersecurity asking, does anyone know what this account does?
00:19:21.599 --> 00:19:23.680
And an uncomfortable silence.
00:19:24.079 --> 00:19:25.920
So what should you actually do?
00:19:26.559 --> 00:19:31.359
Start by finding the agents, not just the big enterprise AI platform.
00:19:31.599 --> 00:19:43.599
Look at what's being built in departments, automation platforms, development teams, customer service, security, IT operations, low-code environments, vendor products.
00:19:43.839 --> 00:19:47.279
You may already have more agentic behavior than you realize.
00:19:47.599 --> 00:19:49.119
Then inventory authority.
00:19:49.359 --> 00:19:52.480
For each agent ask, what identity does it use?
00:19:52.720 --> 00:19:54.160
What data can it access?
00:19:54.319 --> 00:19:55.759
What tools can it invoke?
00:19:56.000 --> 00:19:57.519
What actions can it perform?
00:19:57.759 --> 00:19:59.359
Which systems can it modify?
00:19:59.519 --> 00:20:01.440
Where does it require human approval?
00:20:01.599 --> 00:20:02.240
Who owns it?
00:20:02.400 --> 00:20:03.599
How is it monitored?
00:20:03.759 --> 00:20:05.279
And how do we disable it?
00:20:05.440 --> 00:20:07.039
And classify the actions.
00:20:07.200 --> 00:20:09.839
Not every capability carries the same risk.
00:20:10.079 --> 00:20:14.000
Reading a knowledge article is different from changing payroll information.
00:20:14.240 --> 00:20:17.200
Drafting an email is different from sending one.
00:20:17.519 --> 00:20:20.319
Recommending access is different from granting it.
00:20:20.640 --> 00:20:24.000
Creating a purchase request is different from approving payment.
00:20:24.240 --> 00:20:27.440
That distinction gives you somewhere practical to start.
00:20:27.680 --> 00:20:29.279
Then test the boundaries.
00:20:29.519 --> 00:20:33.119
Don't only test whether the agent performs the intended workflow.
00:20:33.440 --> 00:20:48.319
Test what happens when information is incomplete, when instructions conflict, when a user asks it to do something outside their authority, when external content contains unexpected instructions, and when the agent simply gets something wrong.
00:20:48.559 --> 00:20:52.799
The goal isn't to prove the agent works, the demo already did that.
00:20:53.039 --> 00:20:55.200
The goal is to understand how it fails.
00:20:55.440 --> 00:20:58.240
That's usually where security gets interesting.
00:21:01.200 --> 00:21:03.279
And now this week's multiplier.
00:21:03.440 --> 00:21:08.160
Pick one AI agent your organization is using, building, or seriously considering.
00:21:08.319 --> 00:21:10.079
Then ask five questions.
00:21:10.319 --> 00:21:11.920
What identity does it use?
00:21:12.079 --> 00:21:13.519
What data can it access?
00:21:13.680 --> 00:21:15.039
What actions can it take?
00:21:15.279 --> 00:21:16.720
Who can authorize those actions?
00:21:16.799 --> 00:21:18.640
And finally, how do we stop it?
00:21:18.799 --> 00:21:21.039
Not how do we ask it politely to stop.
00:21:21.279 --> 00:21:24.400
How do we actually remove its ability to act?
00:21:24.799 --> 00:21:30.880
Disable the identity, revoke the token, remove the tool, terminate the workflow.
00:21:31.119 --> 00:21:32.640
Whatever the mechanism is.
00:21:32.880 --> 00:21:36.880
If you can answer all five clearly, you've got the beginnings of a security model.
00:21:37.200 --> 00:21:45.039
If you can't, the agent may already have more autonomy than your governance does, and that's probably worth fixing before we give it another tool.
00:21:45.200 --> 00:21:47.039
That's this week's multiplier.
00:21:47.359 --> 00:21:52.079
AI agents represent a genuinely important change in enterprise technology.
00:21:52.319 --> 00:21:58.400
Not because they're magically intelligent, and not because every agent is going to become autonomous.
00:21:58.640 --> 00:22:03.839
The important change is that AI is moving closer to action, and action requires authority.
00:22:04.000 --> 00:22:07.119
That's the security model I think we need to focus on.
00:22:07.359 --> 00:22:11.920
In episode three we talked about identity helping determine what AI can know.
00:22:12.160 --> 00:22:17.119
With agents, identity and authorization increasingly determine what AI can do.
00:22:17.359 --> 00:22:23.200
And the moment AI can do something, familiar security principles become extremely relevant.
00:22:23.519 --> 00:22:35.279
Least privilege, strong identity, separation of duties, approval, monitoring, auditability, life cycle management, and the ability to revoke access.
00:22:35.440 --> 00:22:36.960
These aren't new ideas.
00:22:37.119 --> 00:22:38.960
And that's actually encouraging.
00:22:39.200 --> 00:22:45.200
We don't need to invent cybersecurity from scratch because somebody added the word agent to the architecture diagram.
00:22:45.759 --> 00:22:49.200
We need to apply what we've learned to a new kind of actor.
00:22:49.440 --> 00:22:51.279
The opportunity is enormous.
00:22:51.519 --> 00:23:05.279
Agents can remove repetitive work, accelerate processes, help employees, improve security operations, connect systems, and potentially make organizations much more productive.
00:23:05.519 --> 00:23:10.319
But every time we increase autonomy, we should understand the authority we're delegating.
00:23:10.480 --> 00:23:13.839
Because an AI system that can answer a question is useful.
00:23:14.000 --> 00:23:17.279
An AI system that can take action is powerful.
00:23:17.519 --> 00:23:19.680
And power needs boundaries.
00:23:20.000 --> 00:23:23.359
That's it for this episode of AI Security Multipliers.
00:23:23.519 --> 00:23:28.400
If you enjoyed the episode or found it useful, please follow or subscribe to the show.
00:23:28.559 --> 00:23:33.440
And if you know somebody who's building AI agents, send this episode their way.
00:23:33.680 --> 00:23:37.519
Preferably before they give the agent administrative access.
00:23:37.680 --> 00:23:50.720
I'd also really like to hear from you if there's something you disagree with, a topic you think we should explore, or an AI or cybersecurity problem you're dealing with in your own organization, send it to me.
00:23:50.880 --> 00:24:00.880
And if you've already built an autonomous agent that can modify production, approve payments, and create its own credentials, I'd definitely like to hear from you.
00:24:01.119 --> 00:24:03.839
Although perhaps after you've found the off switch.
00:24:04.079 --> 00:24:06.799
I'm Steve, and I'll see you next time.