Fortinet Just Confirmed What We've Been Saying. Here's What They Can't Fix.

Written by Mark Rogge, CEO & Founder, EnforceAuth

This morning, Fortinet unveiled FortiAI 8.0.

Read the announcement and one message is unmistakable: AI security is now the central focus of enterprise infrastructure. Not a feature buried in a release note. Not a checkbox for analyst briefings. The feature. Urgent enough to anchor a major platform release from one of the largest cybersecurity companies on earth.

I want to be clear about what that means.

Fortinet didn't create this problem. They validated it. And when a company of that scale makes AI security the centerpiece of its flagship OS, they're confirming something every CISO and security architect already feels: the AI security problem is real, it's already in your environment, and the industry isn't ready for it.

So thank you, Fortinet. You just made this conversation a lot easier.

What FortiAI 8.0 Actually Delivers

FortiAI 8.0 brings meaningful capabilities at the perimeter. Shadow AI visibility. MCF and agent-to-agent traffic inspection. AI-aware application control at the SASE layer. Enhanced DLP for data exfiltration. Real stuff. Stuff that solves real problems.

And it addresses exactly zero percent of what happens after the perimeter.

Here's the mental model that matters.

Your AI agent is already inside the building. It authenticated. It passed the firewall. FortiAI knows it came in. They can see what tools it's using. They can monitor its traffic patterns. Good. All of that is valuable.

Now ask the question nobody is asking.

What is this agent authorized to do once it's inside? Who's verifying that, continuously, for every action it takes? Which data repositories can it read? Which APIs can it call without a human in the loop? When its permissions should change mid-session, does anyone know? When a compromised credential hits an existing agentic session, what happens?

A firewall can't answer those questions. SASE visibility can't answer them. Shadow AI detection can't answer them.

Authorization answers them.

And this is precisely the gap that exists, unaddressed and growing every day, in virtually every enterprise AI deployment on earth.

Why Isn't Visibility the Same as Authorization?

I spent years at Styra working on OPA, watching organizations confuse identity verification with access governance. The same pattern is playing out again, just with different vendor names on the slide deck. Fortinet can tell you an agent walked through the door. They can describe what it looks like, what tools it's carrying, which hallway it turned down.

But they can't tell you whether it should be in that hallway at all.

We call this the Authorization Gap. It sits between two layers that most security teams treat as one thing but are actually quite different.

AI safety is the layer you've probably already invested in. Content filters. Prompt guardrails. Behavior alignment. It keeps your AI polite and prevents it from saying something offensive or biased. Important work.

AI security is the layer most organizations haven't built yet. Runtime enforcement of who and what can do what, across every identity, every action, every system, continuously. Not a scan. Not a report. Enforcement.

Look, I've watched this confusion play out as incident reports at three different companies. A polite AI agent doesn't equal a secure one, and a visible agent sure as hell isn't an authorized one. An agent that passes every content filter and every guardrail can still access customer PII it has no business touching, because the authentication layer said "come on in" and nobody ever defined what the boundaries of "in" actually look like.

Continuous Identity Verification, Not Just Authentication at the Door

Fortinet's perimeter protects the boundary. Identity providers like Okta and Entra handle authentication at login. Their model was designed for humans sitting at browsers, clicking through workflows one at a time. It was not designed for AI agents making thousands of autonomous decisions per session, using ephemeral API keys, shared service environments, and non-human identities that run authenticated 24/7 in production.

The scale of the non-human identity problem alone should give you pause. CyberArk's research found that machine identities outnumber human identities 45 to 1 in the average enterprise. And 86% of CISOs say they don't enforce access policies for AI-specific identities, according to the 2026 CISO AI Risk Report.

Here's how different that operating model really is. A human logs in, does some work, goes to lunch, comes back, maybe triggers a re-auth after a timeout. Short window between authentication and action. Limited blast radius.

An AI agent authenticates once and runs for hours. Days, sometimes. It chains API calls, invokes tools, queries databases, and makes decisions at a pace no human could match. Every one of those actions happens under the same credential issued at session start. And if the context changes mid-session, if a data classification shifts, if a risk score spikes, if a regulation takes effect? Nothing in the perimeter or authentication layer responds. Nobody's watching.

EnforceAuth enforces continuous identity verification and authorization for every identity, human and non-human, across every action. Not at login. Not at session start. Every single action.

Your AI agent doesn't get a hall pass. It gets authorized.

Four Domains. One Policy Engine.

Fragmented tools create blind spots. Most vendors cover one domain, maybe two. So why do we keep pretending that stitching four point solutions together constitutes a security posture?

EnforceAuth enforces authorization across all four operational domains simultaneously. Here's what that actually looks like in practice: at the application layer, every API call and service interaction gets authorized against policy in real time, not "can this agent call this endpoint" in the abstract, but "can this agent, with this context, access this specific resource, given current policy." Per request, not per session. At the infrastructure layer, every cloud resource, every Kubernetes workload, every infra-level operation is governed by policy-as-code your security team controls. If your authorization story for infrastructure is "we check IAM roles at deployment time," you're governing the 2019 version of this problem. At the data layer, it's about who can read it, write it, move it, train on it. An agent might have a valid token granting database access. That doesn't mean it should see every row. Row-level, column-level, and attribute-level enforcement is a separate surface entirely, one where firewalls have zero visibility.

But the domain that matters most right now is AI workloads, because it didn't exist before agents. Every agent action, every model invocation, every autonomous decision gets authorized, logged, and auditable. Not because the agent is polite. Because the authorization layer says so. An agent authorized to call a specific tool at 2 PM might not be authorized at 2:15 PM if the context shifted. That kind of continuous, contextual evaluation sits entirely outside what any perimeter platform can govern.

One policy engine. Every identity. Every layer. No gaps between tools and no blind spots between domains.

Authorization That Scales Like Software

Most authorization today is managed through UIs, spreadsheets, and tribal knowledge. I've seen it firsthand at more organizations than I can count. A shared Google Sheet labeled "Agent Permissions" with color-coded rows nobody's updated since Q3. That doesn't scale. It doesn't test. It doesn't deploy at the speed your engineering team ships code.

EnforceAuth authorization policies are code. Written in a policy language your team controls, versioned in git, tested in CI/CD, reviewed in pull requests, deployed like any other infrastructure. Built on OPA with native Cedar and Zanzibar compatibility, so your team isn't starting from scratch or locked into a proprietary language.

When your AI deployment changes, and it will change constantly, your authorization posture changes with it. Not six weeks later when someone remembers to update the RBAC configuration. Immediately. Policy-as-code is table stakes at this point. Runtime enforcement is what actually matters.

Compliance-Ready by Default

DORA enforcement is active. The EU AI Act hits its high-risk system deadlines in August 2026. SOC 2, HIPAA, and ISO 27001 don't care that your AI agents ran fast. They care whether they ran authorized.

Point is, auditors aren't going to be impressed by your traffic dashboards. EnforceAuth ships with pre-built compliance frameworks that map your authorization posture directly to regulatory requirements. Every decision logged. Every policy change tracked. Every agent action auditable. What used to take weeks of audit prep now takes hours, because the evidence is baked into the enforcement layer itself.

Walk into your next board meeting and answer the question, "Are our AI systems secure?" with evidence. Not hope.

What Does a Typical Enterprise AI Authorization Audit Reveal?

Here's what an honest assessment of most enterprise AI deployments looks like today. I've seen variations of this list at a dozen different organizations over the past year, and at this point I could practically fill in the findings before the assessment starts.

• AI agents provisioned with overly broad permissions because scoping them properly would have slowed down the pilot
• Service accounts with no expiration, no rotation, no audit trail
• Multiple authorization silos across different applications with no unified policy or visibility
• Non-human identities running in production that haven't been re-evaluated since deployment
• No ability to reconstruct "what did this agent do and was each action authorized?"

None of this is a networking problem. A next-gen firewall can't fix it. SASE visibility can't fix it. Data protection within the firewall can't fix it.

And the financial exposure is not theoretical. IBM's 2024 Cost of a Data Breach report found that organizations dealing with shadow AI incidents faced breach costs averaging $870,000 higher than those without shadow AI involvement.

It's an authorization problem. It requires an authorization solution.

Common Questions About AI Security Beyond the Perimeter

What is FortiAI 8.0?

FortiAI 8.0 is Fortinet's major platform update making AI security the centerpiece of FortiOS. It delivers perimeter-level capabilities including shadow AI visibility, agent-to-agent traffic inspection, AI-aware application control at the SASE layer, and enhanced DLP. It is strong work at the network boundary but does not address runtime authorization for AI agents operating inside the environment.

What is the difference between AI safety and AI security?

AI safety focuses on content filters, prompt guardrails, and behavior alignment. It keeps your AI from generating harmful output. AI security is the runtime enforcement layer: who and what can do what, across every identity, every action, every system, continuously. A polite agent that passes every guardrail can still access data it shouldn't.

What is the Authorization Gap?

The Authorization Gap is the space between authentication (verifying identity) and authorization (enforcing what that identity can do at the action level, continuously). Most enterprises have invested heavily in authentication and perimeter security but haven't built runtime authorization for AI agents. With machine identities outnumbering humans 45 to 1, the gap is wide and growing.

What is policy-as-code for AI authorization?

Policy-as-code means writing authorization rules in a structured language like OPA's Rego or Cedar, storing them in version control, testing them in CI/CD pipelines, and deploying them like infrastructure. It replaces manual RBAC configurations with auditable, testable code that changes at the speed your engineering team ships.

How does EnforceAuth differ from perimeter security like Fortinet?

Perimeter security governs what crosses the network boundary: traffic inspection, shadow AI detection, data exfiltration prevention. EnforceAuth governs what happens after the boundary, enforcing fine-grained authorization for every action an AI agent takes across applications, infrastructure, data, and AI workloads. Fortinet sees that an agent entered. EnforceAuth determines whether it's permitted to open each specific door.

The Conversation Every CISO Should Be Having This Week

When your board asks whether your AI systems are secure, and they're asking or they will be soon, the answer can't be "we have visibility into our AI traffic."

Visibility isn't enforcement. You can watch an agent all day long and still have no control over what it does next.

The answer needs to be: every identity, human and non-human, is continuously authorized for every action it takes. Every AI workflow is governed by enforceable policy. Every authorization decision is logged, auditable, and compliant.

That's the answer EnforceAuth makes possible.

If your organization has AI agents in production, or is deploying them in the next six months, ask one question this week. When an AI agent takes an action in our environment, what's the authorization check that determines whether it's permitted to do so, where does that check execute, and does it verify on every action?

If the answer is "the network layer," that's the perimeter, not the authorization layer. If the answer is "the guardrails," that's safety, not security. And if the answer trails off into silence, that's the Authorization Gap. It is open in your environment today.

EnforceAuth closes it. If you're running agents without authorization controls, we should probably talk.