Part 4 of 4
AI Is Moving Faster Than the Operating Model Around It
Treat High-Impact AI Like a Privileged System
At some point, an AI system stops behaving like a feature and starts behaving like a privileged actor.
If it can access critical data, influence business decisions, change production systems, communicate with customers, or make commitments on behalf of the organization, the question is no longer simply whether the model performs well.
The question becomes: How privileged is this system?
Security already has useful models for thinking about that.
Microsoft introduced the Active Directory Administrative Tier Model more than a decade ago to separate highly privileged identities and systems from lower-trust environments.
The underlying principle is simple:
The more power an identity has over critical systems, the more carefully it should be protected. The same idea applies to AI.
As an AI system gains Decide and Act authority, its effective privilege increases. As the consequences of its actions increase and the ability to reverse those actions decreases, the system begins moving closer to what I would consider a Tier 0-like asset.
AI introduces another kind of privilege
Traditional tiering primarily looks at technical control planes.
- What systems can this account administer?
- What infrastructure can it modify?
- What other identities can it control?
AI introduces another dimension: business privilege.
An AI system may have very little traditional administrative access and still:
- review contracts, communicate with customers, influence pricing, make safety recommendations,
- create regulated statements, authorize commitments, or materially affect revenue.
That means AI privilege has to account for both technical blast radius and business consequence.
An AI reviewing customer contracts might not look like a Tier 0 system from an infrastructure diagram but if one incorrect recommendation can create a multimillion-dollar obligation, the business may disagree.
Map AI risk to the mission
This is where technical security language often stops being useful. Business leaders understand revenue.
When I worked incident response, I saw something repeatedly: executives discovered which technical systems were truly essential to revenue for the first time during an incident.
The military uses the concept of mission mapping which means understanding which people, processes, and technologies directly contribute to accomplishing a mission.
Businesses can use the same idea. Imagine situations where different systems or networks go down and ask yourself these questions.
- Could you still generate revenue?
- Could you deliver your product?
- Could you serve your customers?
Those dependencies deserve different treatment.
Now apply that model to AI.
Do not ask only: What task does this agent perform?
Ask: How directly does this system affect the company's ability to accomplish its mission?
If it makes one incorrect decision, how much revenue could be at risk? What happens if it makes the same bad decision 10,000 times before anyone notices? Could it create a contractual obligation? Regulatory exposure? Customer harm? Safety consequences?
Those questions move the conversation from task efficiency to business consequence.
That is where AI risk belongs.
High-impact AI should look like a high-impact system
Once we identify a high-impact AI system, the controls should look familiar.
- Dedicated identity.
- Least privilege.
- Environment isolation where appropriate.
- Enhanced logging.
- Longer retention.
- Continuous monitoring.
- Detection and response capabilities.
- Control testing.
- Rollback.
- Recovery.
- And clear ownership.
The exact implementation will be new because the technology is new. The underlying security principles are not. This is why I believe AI security will mature into its own security discipline in much the same way cloud security did. The expertise required to build an AI system is not automatically the expertise required to secure one. The answer is not to force AI engineers to become security engineers.
It is to have both disciplines design the architecture together.
Make the environment trustworthy when AI is wrong
A useful operating model can be summarized in three stages.
Understand.
Know what process the AI enters, what data it sees, which identity it uses, what authority it possesses, and how the workflow maps to business outcomes.
Bound and verify.
Prefer deterministic controls where they are practical. Require stronger evidence and governance as authority and consequence increase. Define what meaningful human oversight actually means.
Observe and recover.
Make the system auditable. Scale logging to risk. Monitor high-authority agents like privileged systems. Build detection and response capabilities. Know how to stop, contain, and reverse bad outcomes.
Then start with discovery.
- Where is AI already operating?
- What can it access?
- What can it decide?
- What can it change?
- What evidence does it preserve?
- And if it makes the wrong decision tomorrow, can you reconstruct exactly what it saw and exactly what it did?
That creates an operating backlog without requiring the business to stop deploying AI while it waits for a perfect governance model.
AI is powerful enough that we should use it but every time we delegate authority to an AI system, we are also accepting uncertainty. The goal should not be to eliminate that uncertainty entirely. Doing so would eliminate much of what makes AI valuable.
The goal is to understand it, decide when the reward justifies it, and engineer the environment accordingly.
Don't build your controls around how smart AI is when it works.
Build them around what can happen when it is wrong.
