Author: Gerard Onorato, CISO, RKON

On the cyber frontier, the fastest gun has become the fastest model. That thought has stuck with me since Anthropic announced Project Glasswing. I just watched Once Upon a Time in the West, great movie, but I’ll skip the analogies. I’m no Leone when it comes to dramatic showdowns.

Back to shop talk. Glasswing isn’t a one-off. It’s the latest, and from what we hear, the greatest, entry in what is now, very clearly, a category. Frontier capability is being aimed straight at the heart of cybersecurity, and what that means for the rest of us trying to stay a half-step ahead of the next breach is being worked out in production, not in the lab.

This Is Now a Category, Not an Announcement

If Glasswing felt like a singular moment, it isn’t. Singular moments in our profession are getting very rare. If something hits you on the head, get your hard hat, because something else is coming.

Think back to when OpenAI launched Aardvark, their agentic security researcher, in 2025. It became Codex Security in 2026 when it was released for enterprise use. Theori followed right after with its own AI discovery platform, Xint. More are on the way, just watch for the signs. What matters most isn’t the tools themselves, but how quickly we move from noticing something new to actually finding new CVEs in real code.

In its first 30 days of beta, OpenAI reported that Codex Security identified 792 critical findings, including 14 CVEs across key projects such as PHP, libssh, and Chromium (OpenAI, March 2026) attackers, nor could we achieve that kind of scanning a year ago.

The Economics Already Shifted

I’m less interested in these tools as cool technical milestones, though they are, and I wish I could be more fascinated by that… I really do. I’m trying to do the math. The economics of vulnerability discovery have changed. Past tense, not will, they have.

We’ve benefited from an imbalance all our careers. Sure, a zero-day can be catastrophic, but finding weaknesses was slow, expensive, and heavily dependent on human expertise. Of course, exploiting them usually took far less effort. Frontier AI is narrowing that gap the moment it lands in the wrong hands. Systems that can search code, reason over complex environments, and identify exploitable conditions scale offensive capability in ways most security teams aren’t built to handle.

Sure, AI helps us defenders, too. The honest question is whether defensive capability can outpace the governance, controls, and operational discipline needed to keep it pointed in the right direction. If the model can help your team find flaws faster, it can do the same for the other side, and attackers won’t be slowed down by your change advisory board, procurement cycle, or quarterly risk review.

Credit Where It’s Due

Credit goes to the labs. Anthropic is presenting Glasswing as a real defensive tool, and OpenAI is doing the same with Codex Security and their Trusted Access for Cyber program, which is an identity and trust framework (OpenAI, February 2026). Whatever you think of these companies, they’re not being naive. Both are taking the dual-use issue seriously.

We can’t afford to be naïve about it either. Once a capability like this exists, and now there are several, the race is about adoption and execution. We get to decide whether these tools become a force multiplier for our defenses or an accelerant for the people trying to kick the doors in. Well, actually, we just get to decide if we want to ignore the boot sounds banging on the outside of the door, or do something about them.

The Implications Are Immediate

• Vulnerability management has to become faster and more risk-driven. The monthly patch cycle is already on borrowed time, and the cadence is getting worse, not better.
• Detection engineering needs to account for automated reconnaissance and much faster exploit iteration than anything in your current threat model.
• Incident response needs to assume attackers will test more paths, more quickly, and with less human friction than your playbook assumes.
• “Patch later” is becoming a more dangerous habit by the month. When public agents are surfacing CVEs at the rates we’re now seeing, the gap between disclosure and weaponization shrinks for everybody.

Security teams are very good at playing the game against our usual foes. We’re less comfortable and slower to admit when the rules of the game change. This year is one of those moments, new rule book folks.

Two Bad Instincts

Right now, we need to avoid two common mistakes: getting too excited or being too skeptical. Overconfidence and complacency are both easy traps. Vendors will promise miracle solutions, and your board will want to know why you haven’t bought one. But that’s not a real strategy.

What You Can Do

Focus on the basics and get ready. The threat landscape is speeding up, even if it’s not glamorous work.

• Inventory your assets. You probably can’t, fully, and that’s a problem. But your threat environment needs to be managed, and you can’t shrink what you don’t inventory.
• Tighten identity controls. Phishing-resistant MFA on your privileged accounts, now, seriously, now. While you’re at it, zero-trust and access reviews. You know what? Review your entire IAM program, and read my new paper on it.
• Improve logging and monitoring with identity context. Don’t just add more telemetry.
• Implement or test segmentation so one compromise doesn’t cascade across the enterprise.
• Minimize time to patch. Assume the window is shorter than it used to be.
• Tabletop your response plan, and stress-test it against a scenario where the attacker iterates at machine speed.
• Use AI where it genuinely strengthens your defense. Evaluate tools now on the market with clear eyes. Keep humans in the loop for production decisions. Keep their hands on the triggers.
• Make sure your business continuity plans are tight, and your risk picture is honest.

In other words, make sure your own house is in order before a fight breaks out.

One More Thought

Here’s what I keep thinking about: Anthropic, OpenAI, and at least one other outside company have all released similar capabilities at the same time. This is what responsible disclosure looks like in this field. That’s what we can see.

This makes the silence from the other categories of actors a lot more conspicuous. State-backed programs. Well-funded criminal operations. The quiet end of the private offensive-security market. If three or four public labs converged on this capability within a year, the working assumption that nobody less talkative got there first or got further stops looking conservative. A bit of me fears that Anthropic and OpenAI were only the first, ethical or commercial enough to disclose. Quiet capability beats public capability every time in this line of work, and the quiet kind doesn’t come with a press release. Or maybe I’m paranoid, but maybe I’m not. Time will tell

Closing

Speed has always mattered in the cyber world, but never this much. That’s the main takeaway. Glasswing, Codex Security, and whatever comes next aren’t just more AI news, they’re signs that the landscape has already changed.

For CISOs, the job now is to recognize these changes, respond calmly, and make sure the best tools are working for your team, not for attackers.

Focus less on flashy new tools and more on what attackers actually use to break in and stay in. That’s what matters. Good luck, we have a lot to do and not much time.

Author: Aaron Rea, Principal Consultant, Cloud Security

I just got back from Google Cloud Next, and after three days of “agentic” being said roughly every eleven seconds, one thing is clear. We are back in a platform-building moment. Not a “Gemini is cool” moment. Not a “let me bolt an LLM onto Lambda” moment. A full-on, this-is-going-to-eat-the-next-five-years platform moment, the same flavor as when containers stopped being a Docker party trick and turned into Kubernetes eating the data center.

The headline was the Gemini Enterprise Agent Platform, Google’s evolution of Vertex AI plus a constellation of new primitives: Agent Studio, Agent Runtime, Agent Identity, Agent Gateway, Agent Observability, Agent Sandbox, Agent Memory Bank, Agent Threat Detection. If you read that list and your brain auto-completed “this is Kubernetes for agents,” you and I are reading the same tea leaves.

The DIY vs. COTS tightrope

Here’s the tension every cloud and platform team is walking into in 2026, whether they’ve named it or not.

On one side, DIY: roll your own agent runtime on raw GKE, wire up your own vector store, glue MCP servers to your service mesh, write your own gateway, build your own audit pipeline. You’ll learn a lot. You’ll also be eighteen months behind, and you’ll own a snowflake your security team has to defend and your auditors have to certify.

On the other side, fully-baked COTS: buy the platform end-to-end, click through the studio, ship to prod, accept whatever lock-in and opaque behavior comes with it. It works until it doesn’t, and now you’re explaining to a regulator why you can’t tell them which model approved a transaction.

The sustainable answer is the middle path: build a platform. Not a magical AI platform. A boring, opinionated, paved-road platform that picks the abstractions you want to be portable across, lets you swap models and runtimes underneath, enforces your security and compliance posture by default, and gives your app teams a paved road that doesn’t require them to learn what gVisor is. Same playbook we ran with K8s a decade ago. Nobody actually wanted to manage etcd; everyone wanted the abstractions on top.

For regulated industries, this isn’t a preference. It’s the only path that produces an auditable, governable agent estate.

What actually shipped that matters

A lot of the 260+ announcements were product marketing, but several are genuinely platform-shaped and worth real attention.

GKE Agent Sandbox. The standout. gVisor-based kernel isolation, the same tech protecting Gemini, capable of 300 sandboxes per second per cluster at sub-second latency, with up to 30% better price-performance on Axion vs. other hyperscalers. If you’re going to let LLM-generated code execute against your infrastructure, traditional container isolation isn’t sufficient, and Agent Sandbox is the first credible primitive that treats “ephemeral, untrusted, single-replica workload” as a first-class K8s concept. It’s based on an open-source controller, so the abstraction is portable across clouds. That matters for any compliance regime that requires demonstrable workload isolation.

Agent Gateway and Agent Identity. These are the unsexy announcements that signal Google is taking enterprise seriously. Every agent gets a workload identity, every action runs through a unified policy enforcement point, every interaction emits audit telemetry. If you’ve ever tried to retrofit identity onto a fleet of microservices that grew up without it, you know why doing this on day one is the difference between a platform and a liability. For SOC 2, HIPAA, PCI, and FedRAMP environments, this is the foundation that makes agent workloads defensible.

TPU 8t / 8i split and Axion N4A going GA. The split into training-optimized (8t) and inference-optimized (8i, with claimed 80% better performance per dollar) is honest about something the industry has been quiet about: the workloads are different, and one chip serving both leaves money and latency on the table. Pair that with Axion N4A delivering up to 2x better price-performance than current-gen x86 for cost-sensitive workloads, and the economic case for putting agent glue code on Arm becomes hard to argue with.

llm-d as a CNCF Sandbox project. A buried but important development. Google is a founding contributor alongside Red Hat, IBM Research, CoreWeave, and NVIDIA, with a stated vision of “any model, any accelerator, any cloud.” If that delivers, distributed inference becomes a portable Kubernetes-native primitive instead of a vendor-locked feature, and CNCF governance gives multi-cloud strategies a real anchor point. That’s the K8s parallel: when CNCF picked a winner in container orchestration, the industry consolidated and the platform layer above it became where differentiation happened.

Wiz + Google Threat Intelligence integration. A direction worth watching closely. The combined platform brings Wiz’s Cloud and AI Security Platform together with Google’s threat intel, and the new AI Application Protection Platform claims code-to-cloud-to-runtime coverage. The acquisition is starting to produce a coherent story for AI workload security, especially for organizations operating across multi-cloud and hybrid footprints.

The K8s parallel, in case it isn’t obvious

Around 2015 you had three camps. Camp A wrote their own Mesos clusters and bespoke schedulers because they were big enough and had the engineering capacity. Camp B bought a PaaS (Heroku, Cloud Foundry, OpenShift early days) and accepted the lock-in. Camp C bet on Kubernetes, which at the time was unfinished, underdocumented, and required deep operational knowledge to run safely.

Camp C ultimately won. Not because K8s was elegant (it wasn’t, and arguably still isn’t), but because it was open enough to invest in, opinionated enough to hide what teams didn’t want to learn, and supported by an ecosystem that compounded year over year. Every serious infrastructure team eventually built their own internal platform on top: paved roads, golden paths, opinionated CD pipelines, internal developer portals. That layer is where the differentiation lived. It’s also where the operational maturity, the security posture, and the compliance evidence lived.

We’re in the same spot with agents. The primitives Google announced (sandboxes, runtimes, identity, gateways, memory, observability) are the new kubelets, ingress controllers, and service meshes. They’re useful. They’re also not a platform. The platform is what gets built on top of them: the opinionated agent SDK your dev teams actually use, the policy bundles that wrap Agent Gateway with your auth and DLP rules, the CI pipeline that runs Agent Simulation against synthetic traffic before anything hits prod, the runbooks and SOC playbooks for when an agent misbehaves at 3am.

If your organization’s plan for the next 18 months is “let each team pick their own framework and ship,” you’re going to relive the fragmentation pain of raw Docker in 2016. Pick your abstractions, build the paved road, and make the easy thing also be the secure, observable, and auditable thing.

A quick word on Vegas and Weezer

Credit where it’s due: Next on the south end of the Strip was the most manageable big cloud conference I’ve done in years. Everything within walking distance, no shuttle bus roulette, no hour-long marches through three casinos to get to a breakout. Other large cloud conferences could learn a thing or two. And Weezer at Allegiant on Tuesday was exactly what 40,000 conference badges needed to remember they’re human beings. Rivers Cuomo’s voice is somehow unchanged since 1996. I have theories.

What to do now that we’re a week out

A week back at your desk, the keynote afterglow has faded, and the question is what actually changes in your roadmap. Four things worth committing to:

1. Pick your abstraction layer and commit. GKE plus Agent Sandbox is a defensible bet because the controller is open-source and the primitives map to K8s concepts your team already understands. If you’re on EKS or AKS, watch llm-d closely. That’s your portability story.
2. Treat agent identity and governance as table stakes. Every agent gets a workload identity, every action gets audited, every tool call goes through a gateway. Do this before you have 50 agents in production, not after. Your auditors will ask, and “we’ll get to it” is not an answer.
3. Build the simulation and eval pipeline before you build the agents. Agent Simulation and Agent Optimizer are interesting; what’s more interesting is having a CI gate that says “this agent regressed on the eval suite, no merge.” That’s a 2026 problem you can solve with 2018 tools.
4. Match your buy-vs-build choices to where your differentiation actually lives. Buy the primitives that are commodity (compute, isolation, identity infrastructure). Invest your engineering effort on the platform layer that encodes your business logic, your security posture, and your operational expertise. That’s the layer that compounds.

The next decade of infrastructure is going to look a lot like the last one. A Cambrian explosion of vendor offerings, a slow consolidation around open primitives, and platform teams quietly doing the unsexy work of turning chaos into a paved road. The teams that win won’t be the ones who picked the right LLM. They’ll be the ones who built the platform that made the LLM choice swappable, the security posture inheritable, and the audit story tellable.

If that platform layer is on your roadmap, and you’re trying to figure out where to start, that conversation is one many of us in the cloud and security community are having right now. Worth having sooner rather than later.

Microsoft’s latest announcement, Microsoft 365 E7 isn’t just another licensing update. It’s a signal of where the market is going.

At RKON, we’re seeing this shift play out in real time with our clients. Organizations are moving from productivity to security to AI-driven operations. The challenge isn’t understanding what E7 is. It’s understanding what to do next and when to implement change.

The Evolution of Microsoft 365 (and Why It Matters Now)

Microsoft’s roadmap has been consistent, even if the pace has accelerated:

• E3 established the modern workplace
• E5 secured it
• E7 is redefining it

Each step builds on the last while also introduces a new layer of complexity.

E3: The Foundation Most Organizations Started With

E3 gave organizations what they needed to modernize:

• Collaboration through Teams and SharePoint
• Standard identity and access management
• Core compliance capabilities

For many, this was the first step in moving away from legacy infrastructure. But today, E3 alone leaves gaps, especially in security and visibility.

E5: Where RKON Sees the Most Immediate Value

E5 introduced enterprise-grade security and compliance and for most organizations, this is still the biggest opportunity today.

At RKON, we consistently see clients underutilizing:

• Microsoft Defender across endpoints, identity, and cloud
• Microsoft Purview for data governance and compliance
• Advanced threat protection and response capabilities

In many cases, clients are:

• Paying for overlapping third-party tools
• Lacking centralized visibility
• Struggling to operationalize security

E5 solves for these challenges when implemented correctly. This is why our guidance is often simple. Before jumping to what’s next, make sure you’re maximizing the value of what you already own.

E7: A Shift to the AI + Human-Driven Enterprise

With E7, Microsoft is introducing something fundamentally different and enabling a new way of working:

• Humans defining intent
• AI copilots assisting with human brilliance leading
• Autonomous agents executing tasks

E7 combines:

• Microsoft 365 E5
• Microsoft 365 Copilot
• Agent 365: a new control plane for managing and securing AI agents

What’s Changing with E7

While the announcement is still evolving, three shifts are clear:

1. AI Is Moving Into Core Operations

What was once experimental is becoming operational. Organizations are moving from testing Copilot to embedding AI across workflows and enabling agents that act on behalf of users.

This creates massive opportunity, but also introduces new risk.

2. Governance Will Define Success

The biggest gap we see today isn’t AI capability, it’s AI governance.

Without the right controls, organizations risk:

• Data exposure
• Compliance issues
• Lack of visibility into AI-driven actions

With E7 and Agent 365, Microsoft is addressing this directly.

At RKON, we see governance as the foundation (not the afterthought) of AI adoption.

3. Security and AI Are Now One Conversation

Historically, security and productivity were separate discussions. That’s no longer the case.

AI requires:

• Secure access to data
• Strong identity controls
• Continuous monitoring

Which means organizations need to think holistically.

When Should You Invest More in Microsoft?

One of the most common questions we’re getting from clients is: “Should we be moving from E3 to E5 to E7 right now?” The answer depends on where you are today.

Stay on E3 if:

• You’re early in your cloud journey
• Security maturity is still developing
• AI is not yet a priority

Invest in E5 if:

• You’re managing multiple security tools
• You need better visibility and response capabilities
• Compliance requirements are increasing
• You want to consolidate and reduce risk

This is where RKON is seeing the strongest ROI today.

Start Planning for E7 if:

• You’re actively deploying Copilot
• You’re exploring AI at scale not just in pilots
• You need governance for AI agents and automation
• You’re rethinking how work gets done across your organization

E7 is less about licensing and more about transformation readiness.

What RKON Recommends Right Now

Even as E7 evolves, there are clear steps organizations should take today:

1. Maximize the Value of Your E5 Investment

We often find:

• Security features that haven’t been deployed
• Compliance tools that aren’t configured
• Capabilities that could replace third-party spend

Unlocking E5 is often the fastest path to value.

2. Build an AI-Ready Foundation

Before scaling AI, organizations need:

• Data classification and governance
• Identity and access controls
• Security visibility across environments

Without this, AI adoption will stall and introduce risk.

3. Move Beyond AI Pilots

If you’re experimenting with Copilot, the next step is to:

• Identify high-impact use cases
• Expand into real workflows
• Measure outcomes

This is where AI starts driving business value.

4. Begin the E7 Conversation Now

Even if you’re not ready to invest, now is the time to ask the strategic questions:

• How will we manage AI agents?
• What governance model do we need?
• How will AI change our operating model?

Final Perspective: This is bigger than licensing. At RKON, we don’t see E7 as just another SKU. The future of work will be defined by how well organizations integrate humans, AI, and automation securely.

A CIO & CISO Perspective on Going from E3 to E5 to E7

For CIOs and CISOs, the value of going from E3 to E5 to E7 becomes clearer when it’s viewed through the lenses that matter most: operational readiness, governance, and cost efficiency.

If you’re already running Microsoft 365 E5 with Copilot and Entra Suite, E7 aligns cleanly with your existing architecture. When E7 becomes available on May 1, it’s worth evaluating as part of your normal licensing and renewal cycle. In many cases, organizations find that E7 simplifies licensing while reducing overall cost, because Agent 365 is effectively included rather than added as a separate control plane.

For organizations using E5 + Copilot but still working through AI governance (guardrails, identity boundaries, auditability, and oversight) you’re not behind. You’re exactly where most enterprises are today. That gap between AI capability and AI control is what Agent 365 is designed to address, and it launches alongside E7.

From a risk and control standpoint, E7 becomes the most straightforward way to operationalize AI responsibly:

• Agent 365 provides visibility and governance for AI agents acting on behalf of users
• Entra Suite strengthens identity as the security boundary for both humans and agents
• Security and compliance are embedded, not bolted on after deployment

It’s also important to recognize that Entra Suite is not only about compliance. It materially improves access security and user experience by enabling:

• Private Access, which allows secure access to internal applications without relying on traditional VPNs
• Internet Access, which helps organizations control and secure access to SaaS applications and the broader internet

From an executive perspective, the takeaway is simple:

Any E5 organization using Copilot or planning to should be actively evaluating E7. April is a natural time to start those conversations, as new SKUs and pricing typically surface and organizations reassess renewals, step‑ups, and add‑ons. For many, E7 is less a “new purchase” and more a cleaner, more governed way to fund and scale AI.

Ready to evaluate your Microsoft strategy?

RKON helps organizations maximize ROI, reduce risk, and control costs by assessing, optimizing, and evolving their Microsoft investments, from E3 to E5 to E7 and whatever comes next. Contact us today.

In a recent RKON‑hosted webinar with our partners, we unpacked what organizations are learning the hard way: there is often a significant gap between where companies think they are and what assessors actually validate. The conversation focused on real assessment experiences, common pitfalls, and what organizations should be doing now to prepare, not just to pass an audit, but to build long‑term security resilience.

Below are the key takeaways every contractor should understand.

Learning on the Fly: Why Self‑Assessments Fall Short

Many organizations entered CMMC confident in their self‑assessments. Once formal assessments began, reality set in.

CMMC third‑party assessors (C3PAOs) conduct rigorous, evidence‑driven evaluations. They ask questions and request proof that organizations doing self‑assessments often didn’t anticipate. The result? A widespread “reality check” moment where contractors discover meaningful gaps between documented intent and operational reality.

CMMC is not about checking boxes. It’s about proving that controls are implemented, operationalized, and working over time.

Scoping Is the Foundation—and the Most Common Failure Point

One of the earliest and most impactful challenges organizations face is scope definition.

Key scoping questions assessors expect clear answers to:

• What is your Controlled Unclassified Information (CUI)?
• What systems, users, and processes fall within your assessment boundary?
• How does information flow into, through, and out of the boundary?

Assessors also evaluate:

• Authoritative asset inventories
• Information flow diagrams
• Security and protection assets
• External Service Providers (ESPs)

These elements are all assessed differently and must be identified early. Poor scoping leads to scope creep, expanded evidence requests, delays, and failed assessments.

Your System Security Plan (SSP) becomes the blueprint for the assessment. If documentation, diagrams, and operational reality aren’t telling the same story, assessors will find the disconnect quickly.

What Assessors Are Consistently Flagging

Across industries, assessment teams are seeing the same patterns emerge.

1. Access Control Gaps

Common issues include:

• Incomplete least‑privilege enforcement
• MFA not applied consistently
• Weak configuration management

Tools alone aren’t enough. Assessors need to see process, enforcement, and review cadence.

2. Audit Logging & Monitoring

One of the biggest gaps for small and mid‑sized organizations:

• Logs exist but aren’t reviewed regularly
• Monitoring isn’t validated or documented
• No evidence of continuous review

Many organizations cannot demonstrate that their controls function consistently over time. Remember, it’s not about a one-time audit. It’s about having a resilient security posture.

3. Configuration Drift

Organizations often deploy security tooling but lack:

• Drift detection
• Change validation
• Ongoing review processes

By the time auditors arrive, environments are stale, undocumented, or misaligned with the SSP.

4. Incident Response That Isn’t Operationalized

Annual tabletop exercises aren’t enough. Assessors expect to see:

• Regular testing
• Documented outcomes
• Evidence that lessons learned were incorporated

Incident response must be alive, not theoretical.

5. Cryptography, PHI/PII, and End‑of‑Life Systems

Assessments are increasingly strict around:

• Validated cryptography
• Legacy or end‑of‑life systems
• Unsupported software still in scope

These areas have become particularly “touchy” in recent assessments.

The Assessment Lifecycle: What to Expect

A full CMMC Level 2 assessment typically unfolds in three phases:

Phase 1: Readiness & Scope Validation

• Boundary confirmation
• ESP identification
• Artifact review
• Gaps surfaced early

Phase 2: Fieldwork & Evidence Review

• Interviews and demonstrations
• Deep technical validation
• The most time‑intensive phase

Phase 3: QA & Determination

• Final review of all 110 controls
• eMASS workflow and submission
• Formal determination

Timelines vary, but organizations should expect 3–4 months end‑to‑end, with buffers for complexity and scope changes. With over 80,000 companies in the DIB and a limited number of C3PAOs, capacity is already a constraint.

Best practice: Engage 9 months ahead of your target date, minimum.

CMMC Is Not a Point‑in‑Time Event

One of the most dangerous mindsets we see is “pass the audit and move on.”

CMMC operates on a three‑year reassessment cycle, with ongoing obligations in between. Drift will happen. M&A will happen. Environments will change.

What matters is:

• Being honest about changes
• Documenting them
• Proving controls remain effective

Organizations that pause evidence collection after certification are setting themselves up for future failure.

The most successful teams are building continuous evidence collection, so audit readiness becomes business‑as‑usual, not a scramble.

Looking Ahead: How CMMC Will Evolve

Over the next 2–3 years, we expect:

• Broader adoption of CMMC‑like requirements beyond DoD
• Civilian agencies applying similar validation logic
• Increased supply‑chain enforcement
• More rigor around demonstrating control effectiveness
• A future Rev 3 transition requiring organizations to evaluate deltas and adapt quickly

CMMC isn’t shrinking. The spider web is expanding.

Why Pre‑Assessments Are Becoming Non‑Negotiable

Given assessor rigor and limited capacity, organizations are increasingly turning to pre‑assessments.

A pre‑assessment with RKON helps organizations:

• Validate scope before it expands
• Identify gaps assessors will flag
• Align documentation with reality
• Reduce surprises during the formal assessment

Think of it as risk reduction, not extra work. This ensures that by the time the auditor comes around, you are confident you can pass.

Many experts see CMMC expanding with civilian agencies beginning to adopt similar frameworks and CMMC-like requirements. It won’t be enough to simply attest to compliance, organizations will need to demonstrate and prove it. Organizations that invest early in strong foundations will have a measurable head start. Learn more in our in-depth whitepaper.

The End Goal Isn’t Passing the Audit

CMMC is ultimately an attestation to something you should already have.

The organizations that succeed aren’t chasing certification they’re building security‑resilient operations. This requires a cultural shift: away from one‑and‑done compliance and toward ongoing operational maturity.

That’s where RKON comes in. Not just to help you pass an assessment, but to help you operationalize security for the long haul. By November, CMMC requirements will begin showing up in contracts. Meaning if you’re not ready, you’re not just behind… you may be ineligible to win or renew DoD work.

If you’re racing the clock, now is the time to understand where you truly stand. Get a pre-assessment today.

The answer isn’t to slow innovation, but to secure it. Responsible AI provides the balance point, embedding governance, risk management, and data protection into every stage of the AI lifecycle. For cloud security leaders, guardrails aren’t optional. Guardrails are the foundation for protecting data, maintaining trust, and enabling growth at scale.

Why Responsible AI Is Essential for Cloud Innovation

AI in the cloud delivers unmatched scalability and speed, enabling organizations to innovate faster than ever before. However, those same advantages also expand the risk surface. When AI is deployed without governance, it can introduce vulnerabilities that compromise data integrity and business continuity.

The consequences of weak guardrails are already clear:

• Data leakage exposing proprietary or regulated information.
• Compliance violations leading to fines, regulatory scrutiny, or blocked operations. · Reputational damage that erodes customer trust and slows AI adoption.

Responsible AI flips the equation. By embedding trust, accountability, and compliance into the AI lifecycle, organizations can harness the power of the cloud without sacrificing security or slowing innovation.

Three Guardrails for Secure, Responsible AI in the Cloud

Responsible AI in the cloud isn’t theory, it’s practice. Enterprises need AI landing zones: secure environments with governance, risk management, and data protection built into daily operations.

At RKON, we see three pillars as essential: governance, risk management, and data protection. Together, they create the foundation for AI that is innovative, secure, and trusted.

But building guardrails isn’t a one-time project. Policies, risks, and data protections must be continually reinforced over time. As AI evolves, so do the threats and compliance requirements. Responsible AI requires continuous governance, not a “set it and forget it” approach.

1. AI Governance in the Cloud

Shadow AI projects spread quickly without governance, introducing risk and inconsistency throughout an organization. Governance establishes the boundaries for how AI is utilized, ensuring that innovation aligns with expectations of compliance, trust, and security.

Best practices include:

• Establishing policies and standards tailored to cloud AI use cases.
• Leveraging frameworks such as the NIST AI RMF, Microsoft Responsible AI, ISO 42001, and Google Responsible AI.
• Embedding accountability into every stage of the AI lifecycle—from development to deployment.

Governance is not static. Defining standards is only the first step; those standards must be monitored, tested, and adapted as AI capabilities advance. Responsible AI means evolving your guardrails as fast as the technology itself evolves.

2. AI Risk Management in Enterprises

AI introduces risks that traditional security models can’t fully anticipate. Shadow AI projects, data misuse, biased models, and compliance gaps don’t just create technical vulnerabilities; they erode customer trust, attract regulatory scrutiny, and put business continuity at risk.

Effective risk management means taking a proactive, ongoing approach:

• Performing regular AI-specific risk assessments.
• Enforcing access controls and least-privilege policies for AI systems.
• Implementing continuous monitoring to detect unusual or high-risk activity.
• Aligning AI risk management directly with broader cloud security programs.

Risk management is never a one-time audit. New AI capabilities introduce new attack surfaces and compliance challenges at a pace traditional controls can’t match.

Responsible AI requires continuous oversight, enabling organizations to stay ahead of risks instead of reacting to them after the damage is already done.

3. Protecting Data in AI Workflows

AI is only as trustworthy as the data it’s built on. If sensitive or regulated information leaks into training sets, inference outputs, or third-party AI models, the damage can be immediate — from regulatory penalties to long-term erosion of customer trust. For enterprises in regulated industries, the stakes couldn’t be higher.

Practical data protection strategies include:

• Classifying data to identify and prioritize sensitive information.
• Encrypting data at rest and in transit to prevent unauthorized access.
• Embedding privacy-by-design principles into AI workflows.
• Preventing regulated or proprietary data from flowing into external AI systems.

When it comes to AI, data protection is never “finished.” Every new dataset or integration introduces fresh risks that require active defense. As models evolve and datasets expand, data protection controls must evolve with them.

Responsible AI requires continuous testing, validation, and refinement of these safeguards. Ensuring that data remains secure, compliant, and trustworthy throughout the AI lifecycle.

How RKON Helps Enterprises Adopt Responsible AI

Adopting Responsible AI in the cloud requires more than policies — it demands deep expertise across security, compliance, and engineering. RKON helps enterprises establish guardrails, enabling them to innovate with confidence and security.

Here’s how we partner with clients:

• Expertise across cloud, security, compliance, and code Our team blends technical expertise with regulatory knowledge, so your AI adoption is innovative and regulator-ready.
• Building AI landing zones with governance and guardrails We build AI landing zones, providing secure foundations for AI adoption that give your teams the freedom to innovate quickly without losing alignment with organizational policies.
• Aligning with industry and regulatory frameworks From NIST AI RMF to cloud provider guidelines, we map Responsible AI practices to the frameworks your board, regulators, and customers expect.
• Delivering prescriptive, preventative, and future-proof solutions Our approach emphasizes preventative controls and future-ready architectures, so today’s AI adoption doesn’t become tomorrow’s technical debt.

By combining governance, risk management, and data protection, RKON enables organizations to accelerate AI adoption with confidence, allowing for innovation without introducing unnecessary risk.

Put Responsible AI Into Practice Today

Responsible AI in the cloud isn’t optional; it’s the foundation for sustainable innovation. Organizations risk data leakage, compliance violations, and reputational damage without guardrails. However, with the proper guardrails in place, enterprises can confidently embrace AI that drives efficiency, growth, and trust.

By embedding governance, risk management, and data protection into every stage of the AI lifecycle, cloud security teams ensure that innovation never comes at the expense of accountability. Responsible AI is the new seatbelt for cloud innovation, invisible when done right and critical when things go wrong.

RKON helps enterprises take this proactive approach by delivering prescriptive, preventative, and future-proof solutions that make Responsible AI not just possible, but practical.

There was no malware involved, and no firewall appears to have been breached in the usual way. The attackers gained privileged access to a central identity and device management console and used its legitimate admin features to carry out the attack. Every action looked like it came from an authorized administrator. Take a moment to let that sink in, then keep reading.

This is exactly the kind of scenario I described in my recent paper, “Identity as the Security Control Plane: Why 2025 Was the Year We Finally Admitted the Network Isn’t in Charge Anymore.” The Stryker incident isn’t a rare exception—it’s proof of my main point, demonstrated by an attacker in real time. Not exactly the validation I wanted.

Identity Is the Battleground. Stryker Proves It.

We’ve spent years strengthening network perimeters, adding endpoint detection tools, and running phishing simulations—and we still need to do those things. But attackers have changed tactics. They no longer need to break down our defenses if they can use valid credentials to get in. Stryker is the latest example. The attackers didn’t exploit a flaw in Intune; they took over a Global Administrator account and used a built-in feature to wipe devices. This is what ‘living off the land’ means when your identity infrastructure is the target. Endpoint detection tools won’t easily catch a legitimate remote wipe command from an authorized admin console. Even if you monitor for it, the alerts can quickly become overwhelming. This attack happened entirely within the identity layer.

In 2025, credential-based attacks made up 22% of all breaches, surpassing every other way attackers first get in. Identity-based attacks increased by 82% year over year. The pattern is clear: attackers steal credentials, use trust relationships, move laterally with legitimate access, and carry out their attack while pretending to be authorized users. That’s exactly what happened to Stryker. In this case, it seems they skipped moving laterally and went straight for the main target, but we’ll learn more as details emerge.

Uncomfortable Questions

If you’re a CISO, the Stryker breach should make you pause and think. How many Global Administrator accounts do you have in your Microsoft environment? Are they protected with phishing-resistant MFA, or are you still using push notifications that can be tricked? Do you require more than one person to approve destructive actions like mass device wipes? Could one compromised account bring down your whole organization tomorrow? These are real questions now, not just hypotheticals.

The Stryker breach proved that a compromised identity can be more damaging than malware. No malicious code was needed. One key opened one door; the platform handled the rest. Stryker is a $25 billion company with 56,000 employees, yet their identity controls failed. Are you confident yours wouldn’t? Unless you invest carefully and stay focused, you probably shouldn’t be.

What You Should Be Doing About It

My full paper goes into these points in detail, but the Stryker breach highlights a few key recommendations. Use phishing-resistant MFA for every privileged account, or better, for everyone. FIDO2 passkeys and hardware security keys tie authentication to specific devices and require physical confirmation. Set up privileged access management with just-in-time elevation and require more than one person to approve major actions. No single account should be able to wipe out all devices without oversight. If one compromised admin credential can wipe 200,000 devices, those controls are missing or not set up for this situation. Both issues can be fixed.

Many of us have seen MDM and UEM platforms as just operational tools, not as critical as domain controllers or identity providers. That thinking has to change. The Stryker attack showed that device management platforms are a central control point. If attackers get in, these platforms can be turned into powerful weapons.

Focus on building identity-aware resilience. Backup infrastructure credentials must live in a separate identity domain. If your backup admin accounts are in the same Entra ID tenant that was compromised, your recovery plan won’t work.

The Bigger Picture

The world is unsettled, and Stryker was targeted by a nation-state actor as a geopolitical statement. But the mechanism, identity compromise leading to administrative abuse, is identical to what financially motivated criminals and ransomware operators use all the time. Geopolitics is the headline. Identity failure is the lesson.

We’ve reached a turning point. Identity is now the real control plane for security, whether we’ve invested in it or not. The Stryker breach is a clear reminder of the difference between understanding this and actually putting it into practice.

I wrote the full paper because CISOs need a practical, evidence-based framework to move toward identity-first security. It covers topics like phishing-resistant MFA, building identity-aware resilience, simplifying detection, managing vendor risk, and governing AI and SaaS. If the Stryker case makes you think you have work to do, you probably do. Read the paper and start making changes.

Focus on real solutions. Strengthen your defenses where attacks are actually happening.

A Note on the Use of AI in This Document

This document, its outline, opinions, and initial verbiage were created manually. AI tools were used in editing, research, and refinement of this document for readability.