AI Risks and Building a Secure AI Program

Executive Summary

AI has moved from experiment to infrastructure. 88% of organizations now use AI in at least one business function, and more than 80% of the Fortune 500 are already running AI agents in production. These systems have stopped simply answering questions. They now plan, decide, and act on your data.

Security has not kept pace. 97% of the organizations that suffered an AI-related breach lacked basic AI access controls, and reported AI incidents rose to 362 in 2025, up from 233 the year before. We see the same pattern in almost every enterprise we work with. Adoption raced ahead while visibility, ownership, and controls fell behind. What used to be an IT concern is now sitting on the enterprise risk register.

This edition sets out a practical way to close that gap: one mental model for reasoning about any AI system, seven control domains that line up with the major frameworks, and a 90-day path from scattered pilots to a governed program.

AI Risk Is Now Enterprise Risk

Four data points frame the moment:

• 88% of organizations use AI in at least one business function (McKinsey, State of AI 2025)
• 80%+ of the Fortune 500 are deploying AI agents in production (Microsoft, 2025 telemetry)
• 97% of AI-breached organizations lacked AI access controls (IBM, Cost of a Data Breach 2025)
• 362 AI incidents reported in 2025, up from 233 the prior year (Stanford HAI, AI Index 2026)

Adoption is now near-universal, and it is increasingly agentic: the systems don't only generate output, they take action. Governance and controls are still catching up. Once a wrong answer can trigger a wrong action, the cost of that lag stops being theoretical.

Why Traditional Security Doesn't Cover AI

Most of our security controls rest on three assumptions. AI breaks all three, and each break opens a new risk that needs a new control.

‍

The point for security leaders is straightforward. AI has to be governed on its own terms. Bolting it onto a program designed for deterministic software with a fixed boundary won't hold.

The Map: Where AI Crosses Your Trust Boundaries

Every AI pattern crosses a different trust boundary, meaning the point where your data or your control passes to something you don't own. Once you know which boundary is being crossed, you know where the risk actually sits.

‍

Whether you consume (you control the config and the data, but not the model) or build (you own the architecture), the risk comes down to the same two things: what the AI can see, and what it can do.

One Mental Model: What It Can See × What It Can Do

You don't need a separate risk framework for every tool. Two questions are enough to place any AI system:

1. What can it see? The sensitivity of the data it can reach.
2. What can it do? The authority it holds to take action.

Plot those two against each other and four postures fall out:

• ENABLE (low data sensitivity, low authority). Light touch, move fast. Think marketing copy generation or code-docs generation.
• CONTROL (low sensitivity, high authority). Constrain what it can do. Think DevOps automation agents or coding assistants running in CI.
• GOVERN (high sensitivity, low authority). Lock down the data. Think internal knowledge chatbots or fraud and risk scoring.
• ASSURE (high sensitivity, high authority). The highest bar before you scale. Think customer support agents or payments and ops agents.

A third factor sits underneath the grid: the pattern, or how the system is actually built. The same box can call for very different controls depending on whether it's RAG, fine-tuned, agentic, or MCP-federated. Same posture, different plumbing, different safeguards.

The AI Posture Model: what it can see × what it can do.

The model in use

Here's how AI that's already in production sorts against the model:

From Patterns to Program: Seven Control Domains

The per-use-case controls roll up into seven domains. Each one is dialed to the system's posture, so it stays light for ENABLE and gets exhaustive for ASSURE.

3. Inventory and visibility. Discover every AI system and agent, keep one register with an owner for each, and flag what's shadow versus sanctioned.
4. Data controls. Classify by sensitivity, mask and redact PII, track data lineage, and limit egress to approved models.
5. Identity and access. Scope model, data, and tool access. Apply least privilege and just-in-time access, with human approvals for high-impact actions.
6. Architecture assurance. Threat-model per pattern, build in guardrails, evals, and a secure SDLC, and reuse reference patterns rather than reinventing them.
7. Red teaming and testing. Test for prompt injection, jailbreaks, and agent and RAG abuse, both before release and on an ongoing basis.
8. Runtime defense and IR. Run AI-aware detections, monitor output and model behavior, and keep a kill switch and IR playbooks ready.
9. Vendor and supply chain. Vet models, tools, and MCP servers, track provenance with SBOM and SCA, and monitor behavior over time.

These seven map cleanly onto the frameworks most CIOs are already being measured against: NIST AI RMF, ISO/IEC 42001, OWASP LLM and Agentic, MITRE ATLAS, and Google SAIF. Use the frameworks to check your coverage, not as a badge to bolt on. If one of them names a risk your seven domains can't hold, that's the gap to close.

The Blind Spot: You Can't Govern What You Can't See

None of this works if you can't see it. Shadow AI is every one of these patterns running ungoverned and invisible. You carry the full risk with none of the controls, and often with no way to know it's even there.

The one job unique to shadow AI is finding it. Once it's found and sanctioned, you govern it like everything else, through the same see × do × pattern model.

• Discover. This is the part that's specific to shadow AI: OAuth and connector audits, SaaS and network telemetry, a browser-extension inventory, and an expense scan for AI spend.
• Decide. Triage by data and authority. Either sanction the tool with an owner and guardrails, or block it and point the team at an approved alternative. Give people a fast-track path so they don't feel they have to hide it.
• Into the model. Once sanctioned, it's just another system. Sort it by see × do × pattern, apply the seven control domains, and it stops being “shadow” and becomes governed.

A 90-Day Path (Discover → Govern → Assure)

You can move now in three focused phases, and prove value before scaling the commitment.

Days 0–30 · DISCOVER. Inventory AI across all patterns, surface the shadow AI, tier every system by see × do × pattern, and land a few quick-win data and access fixes.

Days 30–60 · GOVERN. Publish an AI usage policy and a sanctioned tool catalogue. Get connector and OAuth governance in place, set secure-by-design standards, and map your controls to SAIF and NIST AI RMF.

Days 60–90 · ASSURE. Red-team the highest-risk systems, stand up runtime detection and IR playbooks, and produce a board-ready posture report with a roadmap to scale safely.

The starting ask is small on purpose: a 30-day discovery. Find your AI, sort it with the model, and you have a program instead of a scatter-gun.

Strategic Recommendations for CIOs and CISOs

1. Treat AI as an enterprise-risk surface, not an IT feature. The risk isn't the model itself. It's what the model can see and what it can do, so govern it on those terms.
2. Use one mental model across every AI system. What can it see, what can it do places any tool in minutes and keeps your controls consistent as the estate grows.
3. Start with discovery, because shadow AI is where the real exposure lives. OAuth audits, SaaS telemetry, browser extensions, and spend scans will surface the systems running with no owner and no control.
4. Put the tightest controls where authority is highest. Agentic and SDLC systems that can act need scoped tools, approvals, and a kill switch before they scale, not after an incident.
5. Use frameworks to verify coverage. Map the seven domains to NIST AI RMF, ISO 42001, OWASP, MITRE ATLAS, and SAIF, then close whatever they surface that your controls can't hold.
6. Give the board a posture it can read. A one-page view of coverage, ownership, and open risk, trended quarter over quarter, moves AI from a source of anxiety to a managed program.

Final Word: Govern AI on Its Own Terms

AI adoption is already near-universal, and it is getting more agentic every quarter. The organizations that get hurt won't be the ones that moved fast. They'll be the ones that moved fast without visibility, ownership, or controls. That's what the numbers keep exposing: 97% of AI-breached organizations had no AI access controls, and incident counts are still climbing year over year.

You don't close that gap with a new tool or a longer policy. You close it with a model simple enough to apply to every system, what can it see, what can it do, how is it built, and a program that dials the right controls to each answer.

Start small and start now. Find your AI, sort it with the model, and you'll have a program instead of a scatter-gun. 

Scybers is a specialized global cybersecurity firm with deep front-line expertise in security strategy, security engineering, and security operations management. A Mastercard, Microsoft, and Google Cloud Security Partner, Scybers helps clients across banking, financial services, fintech, healthcare, manufacturing, and high-tech secure their digital businesses with confidence.

Navigate the cybersecurity landscape with confidence — linkedin.com/company/scybers

‍