AI Agents Are Already Working for You. Who’s Managing Them?

Posted on May 11, 2026 by Brent Huston

AI Agents Are Not Applications. They Are Digital Workers.

Most organizations are adopting AI agents faster than they are learning how to govern them.

That is the problem.

A chatbot that answers questions is one thing. An AI agent that can access business data, use tools, trigger workflows, generate artifacts, make recommendations, or alter enterprise state is something else entirely.

At that point, the organization is no longer just deploying software.

It is introducing a new kind of operational actor.

That actor needs identity.

It needs boundaries.

It needs oversight.

It needs evidence.

It needs a human owner.

It needs a kill switch.

In other words, AI agents must be managed more like digital workers than ordinary applications.

The Governance Gap Is Already Here

Across enterprises, mid-market firms, and small businesses, the same pattern is emerging:

Business teams are experimenting with agent workflows.
Security teams are trying to understand the new control surface.
Legal and HR teams are still catching up.
Executives want productivity gains without slowing the business down.
Audit, compliance, and risk teams are asking for evidence that often does not exist.

The dangerous assumption is that existing software governance, SaaS controls, service accounts, and general “responsible AI” policies will be enough.

They usually will not be.

AI agents create new questions:

Who or what is this agent in the enterprise?
What systems can it touch?
What decisions can it influence?
What actions can it take without human approval?
What evidence exists if something goes wrong?
Who owns the agent’s behavior?
How do we suspend, investigate, or retire it?

If leadership cannot answer those questions, the organization does not yet govern its agents.

Why Traditional Software Governance Falls Short

Traditional software governance usually assumes that applications behave within relatively stable boundaries.

Someone writes the code.

Someone approves the deployment.

Someone grants access.

The system then performs the tasks it was designed to perform.

AI agents are different.

They interpret instructions. They infer next steps. They retrieve context. They call tools. They may chain actions together. They can create outputs that look polished and authoritative even when they are incomplete, wrong, or unsafe.

That changes the risk model.

The critical question is no longer simply:

“Can the system perform the task?”

The better question is:

“What happens when the agent performs the task incorrectly, partially, opaquely, or adversarially?”

That is where governance has to catch up.

The Six Planes of Agent Control

In the full e-book, I introduce a practical model called the six planes of agent control:

Identity — Who is this agent in the enterprise?
Policy — What is it allowed to do?
Tool — What can it touch?
Runtime — Where and how does it execute?
Observability — What evidence exists about its behavior?
Governance — Who approved it, owns it, reviews it, and can stop it?

This model gives executives, CISOs, boards, engineering teams, HR, legal, and GRC functions a shared language for managing agentic AI before uncontrolled adoption creates avoidable risk.

It also forces a hard but necessary shift:

Stop governing only the application.

Start governing the actor-like behavior.

Why This Matters Now

The answer is not to reject AI.

That would be strategically weak.

The answer is also not to let every department wire agents into business workflows with broad access, vague accountability, weak logging, and no structured review.

That would be reckless.

The rational path is selective adoption with governance first.

Organizations that get this right will be able to move faster because they can prove where agents exist, what authority they have, what controls apply, and how failures will be contained.

Organizations that get it wrong will eventually face the predictable consequences:

unclear accountability
invisible privilege paths
poor evidence
data exposure
automation bias
workflow drift
legal ambiguity
emergency cleanup after controls should have been designed in from the beginning

This is not a theoretical problem. It is already showing up in real adoption patterns.

Download the Full E-Book

I have released a new e-book:

AI Agents Management Framework: Policy, Procedure, and Governance Controls for Managing AI Agents as Digital Workers

Inside, you will find:

A governance-first model for selective AI adoption
The six planes of agent control
Identity, access, evidence, and oversight patterns
Practical guidance for executives, CISOs, boards, HR, legal, engineering, and GRC teams
Case narratives showing what we are seeing across large enterprises, mid-market firms, and small businesses
Sample policies, procedures, risk tiering worksheets, Agent System Record templates, autonomy budget examples, incident response addenda, and offboarding guidance

The central idea is simple:

If you govern agents like applications, you are governing the wrong thing.

To download the full e-book, register here:

https://signup.microsolved.com/ai-management-e-book/

What You’ll Get When You Register

A practical AI-agent governance blueprint
Download the full AI Agents Management Framework e-book and learn how to treat AI agents as managed digital workers, not ordinary applications. The framework helps leaders define ownership, authority, access, oversight, evidence, and shutdown procedures before agent workflows create unmanaged risk.
Actionable controls you can adapt immediately
The e-book includes practical models for identity, policy, tool access, runtime controls, observability, governance, risk tiering, autonomy budgets, Agent System Records, performance reviews, incident response, and agent offboarding.
Executive-ready guidance for safer AI adoption
Use the framework to help boards, executives, CISOs, HR, legal, engineering, and GRC teams align around a clear operating model for selective AI adoption, stronger accountability, and verifiable control.

About MicroSolved

MicroSolved, Inc. helps organizations improve security, governance, resilience, and operational trust in complex technology environments.

This e-book extends that work into AI-agent governance, with a focus on practical controls for identity, access, oversight, auditing, and enterprise operating model design.

Why My AI Agents Needed CaneCorso as a Security Control Plane

Posted on May 4, 2026 by Brent Huston

AI agents are powerful because they can read, reason, summarize, decide, and act across a wide range of information sources.

That is also what makes them dangerous.

The more useful an agent becomes, the more likely it is to consume data I do not fully trust. Emails. Newsletters. RSS feeds. API responses. Documents sent as attachments. Social media. YouTube transcripts. Scraped search results. Web pages. Translated content. Random bits of text pulled from places where I do not control the author, the formatting, the intent, or the payload.

That is a very different security model than the one most of us are used to.

In traditional applications, we spend a lot of time separating code from data, users from administrators, trusted networks from untrusted networks, and internal systems from the internet. With LLMs and agents, all of those boundaries start to blur. Instructions, context, content, and intent all arrive in the same stream. The model has to reason over that stream, and the agent has to decide what to do with the result.

That is exactly why I wanted a security control plane in front of my own AI agents.

For me, that control plane became CaneCorso™.

CaneCorsoAI

The Problem Was Not Theoretical

My agents support me personally. They monitor and process a wide range of information sources, each usually aligned to a specific focus area, query, or web mission. Some are looking for security research. Some are watching industry news. Some are digesting newsletters. Some are collecting data from APIs, documents, email attachments, social media, transcripts, and scraped search results.

In other words, they spend their time eating untrusted data.

That creates a meaningful risk profile.

I wanted to protect the agents against prompt injection and malformed data attacks. I also wanted to protect upstream and downstream systems from malicious URLs, private data exposure, and unsafe content that could be carried forward into decision-making. These agents are not just producing novelty summaries. Their outputs are used to support decisions.

That matters.

If an agent reads a poisoned page, a malicious email, or a document with hidden instructions, I do not want that content passed directly to the underlying LLM. If the LLM produces something unsafe, misleading, privacy-sensitive, or operationally risky, I do not necessarily want that output passed into the next stage of logic without inspection.

Before CaneCorso, the basic pipeline looked like this:

Collect inputs → summarize/extract → reason/decide → write output.

There was some logging in place for decision analysis, KPIs, and tuning. But logging is not a trust boundary. Observability is useful after the fact. It does not, by itself, prevent hostile or malformed content from entering the LLM context window.

I needed something more like a firewall for agentic workflows.

Moving CaneCorso Into the Agent Path

CaneCorso is now the single control plane for multiple agents in my environment.

Each agent has a defined CaneCorso workflow and API key configured with specific rules and outcomes. From a security practitioner’s perspective, the model feels familiar. It is not unlike firewall or IPS policy tuning. Each workflow can be adjusted based on what the agent does, what data it sees, and what level of risk is acceptable for that mission.

Every agent now sends data through CaneCorso before that data is passed to an LLM.

That is the first and most important control point. Untrusted input does not go straight to the model anymore. It is inspected, filtered, redacted, defanged, and rated before the LLM sees it.

About half of my agents also send the LLM output corpus back through CaneCorso for a second pass before the result is allowed into downstream decision logic. That double-checking pattern has become important for workflows where the output itself may influence actions, prioritization, or further analysis.

The result is a two-layer safety pattern:

Input inspection before the LLM.

Output inspection before downstream use.

That simple architectural shift changes the trust model. I am no longer depending only on model behavior, prompt discipline, or good luck. I have a monitored, auditable control plane sitting in the path.

Token Vault Sanitization and SIEM Logging

One of the other important pieces for me has been token vault sanitization.

Private or sensitive values can be protected before they move through the workflow. That is especially important when agents are handling emails, documents, API results, and mixed internal/external content. Even personal agents can encounter sensitive material, and enterprise agents will almost certainly do so.

I am also sending full transaction details, safety ratings, and decision-making context into my SIEM logs.

That is not just for compliance theater. It gives me a way to perform forensics, review blocked or redacted content, tune policies over time, and understand how different sources behave. If a feed repeatedly triggers injection protections, I can see that. If a workflow is too permissive or too noisy, I can tune it. If something gets blocked, I can understand why.

That feedback loop is essential.

AI security is not a one-and-done configuration exercise. The attack patterns are evolving. The data sources change. The agents change. The business logic changes. The controls need to be visible enough and adjustable enough to keep up.

The Integration Experience

My agents are written in Python, and the CaneCorso documentation made the integration straightforward.

The samples were relevant, accurate, and concise. I started by building a simple API harness from the documentation. Then I tuned that harness for each agent so it used the proper workflow-specific API key. After that, I used the CaneCorso web GUI to tune each workflow.

The first agent took about 30 minutes.

Each following agent took about 10 minutes.

That is an important detail for buyers. This did not turn into a rewrite of my agent stack. It felt more like adding a security middleware layer or API gateway into the agent path. Once the pattern existed, repeating it across agents was simple.

The workflow tuning was also approachable. The GUI presents functional modules in plain language. You can turn capabilities on and off and tune the behavior without needing to write complex detection logic or understand obscure heuristics. Security people will recognize the rhythm: enable controls, test, review outcomes, tune, and repeat.

It felt like firewall or IPS rule tuning, but for AI workflows.

After testing, the agents were back in service. The system has been running seamlessly for weeks with no significant hiccups.

What It Has Caught

So far, I have seen multiple prompt injection redactions. That is not surprising, because some of my agents monitor discussions around LLM threats and AI security. In those environments, malicious or adversarial examples are not theoretical. They show up in the data.

I have also had excellent results with PII redaction and URL defanging.

The URL handling matters more than many people realize. Agents often collect links, summarize pages, follow references, or pass URLs into later workflows. Defanging malicious or suspicious URLs reduces the chance that a downstream system, user, or automation accidentally treats dangerous content as safe.

The PII redaction has also been strong. For agentic workflows, privacy protection has to be built into the pipeline. You do not want every agent team inventing its own ad hoc redaction function, especially in a regulated environment.

Another pleasant surprise has been cross-language support. Some of the feeds my agents process are in languages other than English. CaneCorso has handled injection protection well even when the LLM is being used for translation. That is a big deal, because attackers do not have to limit themselves to English, and global data sources rarely cooperate with neat security assumptions.

Latency has been in the milliseconds per API call on consumer-grade hardware.

Not too shabby.

The Confidence Gain

The biggest practical gain has been confidence.

CaneCorso does not make untrusted data magically trustworthy. No tool does that. But it significantly raises the trust level of the workflow, even when some of the data is known to be hostile or suspicious.

That confidence matters when agents are used for decision support. I am more comfortable letting agents process messy public data because I know the underlying LLMs and downstream systems have another layer of protection. I am not relying solely on system prompts, model alignment, or careful source selection.

The web is untrusted. Email is untrusted. Documents are untrusted. Social media is untrusted. Scraped content is untrusted.

Agent architectures need to be designed with that assumption in mind.

Why Potential Buyers Should Care

Prompt injection is real, prevalent, and dangerous.

We are still early in the evolution of LLM attacks. The patterns are changing quickly, and the impact will grow as agents gain access to more tools, more data, and more authority. It does not take much imagination to see these attacks evolving into deeper compromise, exfiltration, fraud, and ransomware-style workflows.

That is why I think anyone experimenting with or implementing AI agents should be looking closely at this class of control.

If your agents consume data that is not 100% trusted, you need a plan.

That applies to security teams, automation teams, developers building RAG applications, MSPs, MSSPs, executives using personal agents, and organizations building internal agentic workflows. It applies even more strongly to regulated organizations.

In my opinion, regulated organizations implementing agentic workflows without this level of protection are asking for trouble.

The enterprise argument is especially straightforward. It makes sense to have a single, monitored, auditable control plane for agents so every team does not have to roll its own controls. Without that shared layer, each agent team makes its own decisions about redaction, prompt injection protection, URL handling, logging, blocking, alerting, and auditability.

That is expensive.

It is inconsistent.

It is hard to defend.

A shared control plane reduces time, cost, and mistrust. It makes agent adoption safer and helps organizations move toward ROI without pretending the risks are not there.

The Buyer’s Note

CaneCorso is not magic.

No product can provide 100% trust in untrusted data. That is not how security works, and it is definitely not how AI security works.

But the right control can raise the trust level significantly. It can provide a consistent inspection point. It can enforce privacy protections. It can defang URLs. It can redact prompt injection attempts. It can generate logs. It can give security teams something concrete to monitor, tune, and audit.

That is the point.

The organizations that succeed with AI agents will not be the ones that simply connect models to everything and hope for the best. They will be the ones that build control points, observe behavior, tune policies, and treat agentic workflows like the high-impact systems they are becoming.

For my own agents, CaneCorso became that control point.

And once it was in place, I would not want to run them without it.

How to Learn More or Leverage MSI Expertise

If you want to discuss our experience with CaneCorso in more detail, or pilot the tool in your own environment, just get in touch. You can reach us at info@microsolved.com, or give us a call at +1.614.351.1237. We’d be happy to have a zero-pressure discussion with you. Thanks for reading, and stay safe out there!

CaneCorso™ and the Real Problems AI Is Creating for the Business

Posted on April 22, 2026 by Brent Huston

AI didn’t sneak into the enterprise.

It walked in through productivity.

Email triage. Document handling. Support workflows. Internal copilots. Retrieval systems. Early agentic use cases. All of it made sense at the time. All of it still does.

But something changed along the way.

We didn’t just adopt AI—we embedded it into workflows that can influence decisions, expose data, and take action.

That’s where the problem starts.

And it’s exactly where CaneCorso™ is designed to operate.

CaneCorsoAI

AI Risk Isn’t a Model Problem — It’s a Workflow Problem

There’s a persistent misunderstanding in the market right now.

Most conversations about AI security still center on the model—what it knows, how it behaves, whether it can be tricked.

That’s not where the real risk lives.

The real risk shows up when:

Untrusted content enters a workflow
That workflow uses AI to interpret or transform it
And the output influences business operations

That content might come from:

Email
Documents
OCR pipelines
Retrieved knowledge (RAG)
Support tickets
External data sources

Once it’s in the workflow, it’s no longer just data.

It’s influence.

CaneCorso™ exists to control that influence—before it becomes an operational problem.

The Perimeter Moved — Most Organizations Didn’t

Traditional security models assume boundaries.

Applications. Networks. Endpoints. Users.

AI workflows don’t respect those boundaries.

They collapse:

Data
Instructions
Context
Intent

…into the same channel.

That creates an entirely different risk profile:

Prompt injection (direct and indirect)
Data exfiltration through prompt manipulation
RAG poisoning and retrieval contamination
Multimodal attacks through documents and images
Unsafe tool usage triggered by manipulated inputs

These are not theoretical edge cases.

They are natural outcomes of how AI is being used today.

CaneCorso™ addresses this by acting as a shared AI Application Firewall—a control layer that sits in front of real workflows, not just models.

Small Businesses: The Problem Is Safe Adoption

Small organizations aren’t trying to solve AI security academically.

They’re trying to use AI without breaking the business.

They typically don’t have:

Dedicated AI security engineering
Time to build custom controls
Resources to continuously test workflows

But they still face the same risks.

For them, the core problem is simple:

How do we use AI without creating exposure we don’t understand?

CaneCorso™ answers that by providing:

A reusable control layer
Business-safe handling decisions (allow, sanitize, tokenize, block)
Protection against injection and data leakage
Minimal disruption to workflow performance

The goal isn’t perfection.

It’s safe, practical adoption.

Mid-Size Organizations: The Problem Is Inconsistency

Mid-market firms hit a different wall.

AI use spreads quickly—but control does not.

You end up with:

One team securing prompts one way
Another team building ad hoc filters
A third team doing nothing at all

What looks like progress is actually fragmentation.

And fragmentation creates risk.

Because now:

Policies are inconsistent
Logging is inconsistent
Enforcement is inconsistent
Assurance is impossible

CaneCorso™ solves this by introducing a single control plane across workflows.

Not by replacing tools.

But by normalizing how risk is handled across:

Inputs
Prompts
Retrieved data
Outputs

That shift—from local fixes to shared control—is what enables real governance.

Enterprise: The Problem Is Scale and Assurance

Enterprises don’t struggle with whether to use AI.

They struggle with using it at scale without losing control.

The complexity shows up quickly:

More workflows
More data sources
More sensitive content
More downstream impact

Risk concentrates in places like:

Document ingestion pipelines
Retrieval systems
Internal copilots
Agent-driven workflows
Tool-connected AI systems

At that scale, the question changes.

It’s no longer:

“Are we protected?”

It becomes:

“Can we prove we are operating safely?”

CaneCorso™ addresses both sides:

Centralized protection across workflows
Measurable assurance through testing and auditable decisions

Because at enterprise scale, security without evidence is just opinion.

The Difference: Protect the Workflow Without Breaking It

This is where most approaches fail.

Traditional security thinking leans toward blocking.

If something looks suspicious, stop it.

That works—until it breaks the business.

AI workflows are different.

They require more nuance.

CaneCorso™ is built around that reality:

Allow when safe
Sanitize when needed
Tokenize when privacy matters
Block when necessary

That model matters.

Because the goal is not to stop work.

The goal is to keep safe work moving.

The Reality Behind the Threats

It’s easy to focus on the technical attacks:

Prompt injection
Indirect injection
Data exfiltration attempts
RAG poisoning
Tool abuse

But in practice, those attacks succeed because of how systems are built and used.

Developers concatenate untrusted input into prompts
Teams trust retrieved content without validation
Users paste sensitive data into workflows
Agent permissions expand faster than controls
Deployments happen without adversarial testing

These are normal behaviors.

CaneCorso™ works because it assumes those realities—not ideal conditions.

What Actually Changes

When organizations put a control layer like CaneCorso™ in place, the impact is operational.

Not theoretical.

You see:

Reduced likelihood of avoidable AI-driven incidents
Less sensitive data leakage
Fewer workflow failures from brittle controls
Faster, safer AI adoption
A clearer story for auditors, customers, and leadership

That last point matters more than most people realize.

Because AI isn’t just a technology decision anymore.

It’s a business trust decision.

Final Thoughts: Rational AI Security

There are two bad approaches to AI right now.

Move fast and ignore the risk.

Or lock everything down and lose the value.

Neither works.

What organizations actually need is a rational approach:

Small businesses need safe adoption
Mid-size businesses need consistency
Enterprises need scale and assurance

CaneCorso™ aligns with that reality.

Not by trying to “solve AI.”

But by solving the actual problem:

controlling how untrusted content influences real business workflows.

That’s the shift.

And it’s where AI security either becomes operational—or irrelevant.

More Info

To learn more, just give us a call at +1.614.351.1237, or drop us a line at info@microsolved.com. We’d love to walk you through how CaneCorso can help you secure the AI future of your business!

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

Introducing CaneCorso: An AI Application Firewall Built for Real Workflows

Posted on April 16, 2026 by Brent Huston

AI has officially crossed the line from experiment to infrastructure.

Email flows into copilots. Documents feed RAG pipelines. Support tickets trigger agents that can take action. The convenience is real—and so is the risk.

What hasn’t caught up is security.

Most security models were built for a world where inputs were predictable and trust boundaries were well-defined. That world doesn’t exist anymore. Today, untrusted content flows directly into systems that can reason, decide, and act.

That’s exactly where things get interesting—and dangerous.

When Good Data Carries Bad Instructions

One of the biggest misconceptions about AI security is that it’s a model problem. It’s not. It’s a workflow problem.

Attackers don’t need to break in anymore. They ride along with legitimate data—emails, PDFs, tickets, knowledge base entries—and inject instructions that your AI system may interpret as truth.

Think about what that means in practice:

A support ticket that contains hidden instructions
A PDF with embedded prompt injection
A knowledge base entry that poisons RAG outputs
An approval workflow manipulated through summarization

Layer in human behavior—blind trust, over-privileged access, weak validation—and you’ve got a system primed to fail in ways that traditional controls simply won’t catch.

CaneCorsoAI

A More Rational Approach to AI Security

CaneCorso™ takes a different path.

Instead of trying to block everything suspicious (and breaking workflows in the process), it follows what’s described in the Rational AI Security model —security that behaves more like an immune system than a wall.

That means:

Detecting and isolating threats without stopping the system
Treating all inbound content as untrusted by default
Preserving business continuity while reducing risk
Producing measurable, auditable outcomes

This isn’t theoretical. It’s a direct response to how AI systems actually behave in production.

One Control Plane for AI Workflows

At its core, CaneCorso gives you a shared AI Application Firewall—a single control plane that sits between your workflows and your models.

Instead of every team building its own brittle filters, you get consistent, reusable protection across:

Email triage and analysis
RAG pipelines and knowledge systems
Document AI and OCR ingestion
Support and ticketing workflows
Agent-driven automation

The platform delivers:

Runtime decisions: allow, sanitize, tokenize, or block
Privacy controls: redact or tokenize sensitive data before model exposure
Audit-ready logs: reasons, scores, and evidence you can actually use
Adversarial validation: Injection Scanner proves controls before and after deployment

This isn’t just about stopping attacks—it’s about making security operationally usable.

How It Works (Without Breaking Everything)

CaneCorso is built around a simple but effective model:

Connect the workflow
Mailboxes, agents, or document pipelines send raw content through a single control point.
Evaluate risk
The system analyzes both security threats and privacy exposure in real time.
Apply the right action
Policies determine whether content is allowed, sanitized, tokenized, or blocked.
Keep work moving
Safe content continues downstream with context, scores, and auditability intact.

The key difference? It doesn’t rely on hard blocking as the default.

Inline tokenization replaces only the unsafe portion of content—meaning the workflow continues, the business operates, and the risk is neutralized.

Why This Matters Right Now

The perimeter has moved.

AI systems don’t just process data—they act on it. That turns every input into a potential control decision.

The threat landscape outlined in the workflow map highlights the shift:

Indirect prompt injection from internal or trusted sources
Multimodal attacks hidden in images, PDFs, or OCR text
Human-in-the-loop deception during approvals
Over-privileged workflows amplifying impact

These aren’t edge cases. They’re becoming normal operating conditions.

Measurable Security, Not Assumptions

One of the most important shifts CaneCorso introduces is moving security from belief to proof.

The Injection Scanner continuously tests workflows against adversarial scenarios, providing measurable evidence that controls work:

Before deployment
After changes
During audits or customer reviews

That matters for engineering teams. It matters for security teams. And it definitely matters when someone asks, “How do you know this is safe?”

Final Thoughts: Security That Matches Reality

For years, security teams have had to choose between protection and usability.

In the AI era, that trade-off doesn’t hold up.

CaneCorso is built on a simple idea: protect the workflow without breaking it. That means embracing how AI systems actually work—messy inputs, probabilistic outputs, and human decision-making in the loop.

If you’re deploying AI in any meaningful way, the question isn’t whether you’ll face these risks.

It’s whether you’ll be ready when you do.

Learn More

To learn more about CaneCorso, schedule a demo, or discuss your environment:

Email: info@microsolved.com
Phone: +1.614.351.1237
Explainer Video: Click Here To Watch Video

Rethinking Account Lockouts: Why 15 Minutes Isn’t a Strategy

Posted on April 6, 2026 by Brent Huston

There’s a moment in almost every security program where someone asks a deceptively simple question:

“Is 15 minutes a standard account lockout duration?”

The short answer? No.
The more honest answer? It’s common—but often wrong for the environment it’s deployed in.

And I’ve seen more than a few organizations learn that the hard way.

3Errors

The Myth of the “Standard” Lockout

If you go looking for authoritative guidance—from Center for Internet Security, FFIEC, or CISA—you’ll notice something interesting:

They don’t tell you what number to use.

Instead, they consistently emphasize:

Risk-based decision making
Balancing usability and security
Detecting and responding to threats—not just blocking them

That’s not an accident. It’s an acknowledgment that static controls like lockouts are blunt instruments in a very dynamic threat landscape.

What We Actually See in the Real World

Across environments—financial services, healthcare, SaaS, manufacturing—the patterns are pretty consistent:

Setting	Typical Range
Failed attempts before lockout	3–10
Lockout duration	5–30 minutes
Most common default	10–15 minutes

So yes, 15 minutes sits comfortably in the middle.

But “common” and “effective” are not the same thing.

Where 15 Minutes Breaks Down

1. It Punishes Users More Than Attackers

A 15-minute lockout sounds reasonable—until you multiply it.

A clinician locked out mid-shift
A call center agent missing SLAs
A trader unable to access systems during market hours

Now multiply that by repeated lockouts from cached credentials, mobile devices, or service accounts.

You don’t just have a security control—you have an operational problem.

2. It Doesn’t Stop Modern Attacks

Attackers have evolved. Most environments haven’t.

Today’s common attack patterns:

Password spraying (low-and-slow, avoids thresholds)
Credential stuffing (valid credentials, no lockout triggered)

A longer lockout duration doesn’t meaningfully impact either.

If anything, it gives a false sense of security while the real attack path goes untouched.

What Actually Works: A Layered Approach

This is where the conversation needs to shift—from “what’s the right number?” to “what’s the right strategy?”

1. Lockouts Are Supporting Controls—Not Primary Defenses

If you’re relying on lockouts as your main protection, you’re already behind.

At a minimum, you should be pairing with:

MFA everywhere it’s technically feasible
Conditional access (device, location, behavior)
Authentication throttling and smart detection

2. Tune for Risk, Not Defaults

A more balanced configuration tends to look like:

5–10 failed attempts
5–10 minute lockout
Reset counter after a defined cooldown window

This reduces user friction while still slowing down brute-force attempts.

More importantly—it acknowledges that lockouts are a speed bump, not a wall.

3. Progressive Delays Beat Hard Lockouts

One of the most underutilized strategies is progressive delay:

Attempts 1–2 → no delay
Attempts 3–5 → 30–60 second delay
Continued attempts → increasing delay

This approach:

Degrades attacker efficiency
Preserves user productivity
Avoids helpdesk spikes

It’s a far more surgical control than a blanket 15-minute lockout.

4. Detection Over Punishment

Modern security programs don’t just block—they observe.

You should be:

Logging all failed authentication attempts
Alerting on patterns (spraying, geographic anomalies)
Correlating identity signals across systems

Lockouts should be one signal among many—not the primary response.

Implementing This in Active Directory

Let’s get practical.

In on-prem Active Directory, you’re working primarily with Group Policy.

Recommended Baseline

In your domain or fine-grained password policy:

Account lockout threshold: 5–10 attempts
Account lockout duration: 5–10 minutes
Reset account lockout counter after: 10–15 minutes

Where to Configure

Group Policy Management Console (GPMC)
- Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Account Lockout Policy

Advanced Considerations

Use Fine-Grained Password Policies (FGPP) for high-risk accounts (admins, service accounts)
Monitor Event IDs:
- 4625 (failed logon)
- 4740 (account locked out)
Feed logs into your SIEM for correlation and alerting

Implementing This in Microsoft 365

In Microsoft 365, the model shifts significantly.

You don’t directly control “lockout duration” in the same way—because the platform is already applying smart lockout behavior.

Smart Lockout (Azure AD / Entra ID)

Automatically tracks failed attempts
Uses adaptive thresholds
Differentiates between familiar and unfamiliar locations

What You Should Do Instead

1. Enable and Enforce MFA

Conditional Access → Require MFA for all users (with staged rollout if needed)

2. Configure Conditional Access Policies

Block legacy authentication
Require compliant devices
Apply geographic restrictions where appropriate

3. Monitor Identity Signals

Azure AD Sign-in logs
Risky sign-ins and users
Integration with Defender for Identity / Sentinel

4. Tune Smart Lockout (if needed)

Default threshold is typically sufficient
Adjust only if you have a strong operational reason

The Bottom Line

A 15-minute lockout isn’t wrong.

It’s just incomplete.

✔️ It’s common
❌ It’s not a standard
⚠️ It can create more operational pain than security value

The real shift is this:

Stop treating account lockouts as a primary control. Start treating them as part of a layered identity defense strategy.

Because in today’s environment, the goal isn’t just to block access.

It’s to understand it.

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

Update on PromptDefense Suite and AI Security Research

Posted on March 23, 2026 by Brent Huston

Last week, I discussed why and some of how we built the new PromptDefense Suite.

This week, we are discussing the product’s future internally and how we might go to market. This is mainly due to two new capabilities we have built into the product.

The first is an API and workflow automation mechanism. This allows organizations to stand up a single instance of PromptDefense and then use it to protect multiple AI/agent workflows. The code no longer has to be embedded directly in the project; instead, all defensive capabilities and logging can be accessed via an API instance. The API is robust and supports API key restrictions that tie into a rules engine, so that different workflows can have different trust models and actions pre-assigned in an audit-friendly way.

Secondly, we have developed a licensing mechanism that covers protected workflows and skips the per-seat, per-token models that seemed too confusing for most firms looking for these kinds of tools. They told us they wanted a simpler licensing approach, and we developed a new licensing mechanism to make it easy, manageable, and auditable. Our testers have been calling it a win!

As we continue with the beta-testing process and lock down our decisions about where the product is going, the news that drove us to create it continues to flow in. More of our clients are working on agents and AI-integrated workflows, which require this level of protection. While we continue to develop PromptDefender, we are also working to develop and release extended frameworks for AI model, agent, and product management, along with policies, procedures, and vendor risk assessment tools for these frameworks, for our vCISO clients. We’re also busy researching ongoing compliance implementation for AI workflows and agents, and should have more on that shortly.

In the meantime, if you want to discuss AI or agent security, risk management, or other relevant topics, please reach out. We would love to talk with you and help align our modernization capabilities with your emerging needs. You can always email us at info@microsolved.com or call us at +1-614-351-1237.

As always, thanks for reading. Stay safe out there, and stay tuned for more updates.

From Alert Volume to Signal Yield: An Economic Framework for Measuring SOC Effectiveness

Posted on March 2, 2026 by Brent Huston

Six months after a major alert-reduction initiative, a SOC director proudly reports a 42% decrease in daily alerts. The dashboards look cleaner. The queue is shorter. Analysts are no longer drowning.

Leadership applauds the efficiency gains.

Then reality intervenes.

A lateral movement campaign goes undetected for weeks. Analyst burnout hasn’t meaningfully declined. The cost per incident response remains stubbornly flat. And when the board asks a simple question — “Are we more secure now?” — the answer becomes uncomfortable.

Because while alert volume decreased, risk exposure may not have.

This is the uncomfortable truth: alert volume is a throughput metric. It tells you how much work flows through the system. It does not tell you how much value the system produces.

If we want to mature security operations beyond operational tuning, we need to move from counting alerts to measuring signal yield. And to do that, we need to treat detection engineering not as a technical discipline — but as an economic system.

AppSec

The Core Problem: Alert Volume Is a Misleading Metric

At its core, an alert is three things:

A probabilistic signal.
A consumption of analyst time.
A capital allocation decision.

Every alert consumes finite investigative capacity. That capacity is a constrained resource. When you generate an alert, you are implicitly allocating analyst capital to investigate it.

And yet, most SOCs measure success by reducing the number of alerts generated.

The second-order consequence? You optimize for less work, not more value.

When organizations focus on alert reduction alone, they may unintentionally optimize for:

Lower detection sensitivity
Reduced telemetry coverage
Suppressed edge-case detection
Hidden risk accumulation

Alert reduction is not inherently wrong. But it exists on a tradeoff curve. Lower volume can mean higher efficiency — or it can mean blind spots.

The mistake is treating volume reduction as an unqualified win.

If alerts are investments of investigative time, then the right question isn’t “How many alerts do we have?”

It’s:

What is the return on investigative time (ROIT)?

That is the shift from operations to economics.

Introducing Signal Yield: A Pareto Model of Detection Value

In most mature SOCs, alert value follows a Pareto distribution.

Roughly 20% of alert types generate 80% of confirmed incidents.
A small subset of detections produce nearly all high-severity findings.
Entire alert families generate near-zero confirmed outcomes.

Yet we often treat every alert as operationally equivalent.

They are not.

To move forward, we introduce a new measurement model: Signal Yield.

1. Signal Yield Rate (SYR)

SYR = Confirmed Incidents / Total Alerts (per detection family)

This measures the percentage of alerts that produce validated findings.

A detection with a 12% SYR is fundamentally different from one with 0.3%.

2. High-Severity Yield

Critical incidents / Alert type

This isolates which detection logic produces material risk reduction — not just activity.

3. Signal-to-Time Ratio

Confirmed impact per analyst hour consumed.

This reframes alerts in terms of labor economics.

4. Marginal Yield

Additional confirmed incidents per incremental alert volume.

This helps determine where the yield curve flattens.

The Signal Yield Curve

Imagine a curve:

X-axis: Alert volume
Y-axis: Confirmed incident value

At first, as coverage expands, yield increases sharply. Then it begins to flatten. Eventually, additional alerts add minimal incremental value.

Most SOCs operate blindly on this curve.

Signal yield modeling reveals where that flattening begins — and where engineering effort should be concentrated.

This is not theoretical. It is portfolio optimization.

The Economic Layer: Cost Per Confirmed Incident

Operational metrics tell you activity.

Economic metrics tell you efficiency.

Consider:

Cost per Validated Incident (CVI)
Total SOC operating cost / Confirmed incidents

This introduces a critical reframing: security operations produce validated outcomes.

But CVI alone is incomplete. Not all incidents are equal.

So we introduce:

Weighted CVI
Total SOC operating cost / Severity-weighted incidents

Now the system reflects actual risk reduction.

At this point, detection engineering becomes capital allocation.

Each detection family resembles a financial asset:

Some generate consistent high returns.
Some generate noise.
Some consume disproportionate capital for negligible yield.

If a detection consumes 30% of investigative time but produces 2% of validated findings, it is an underperforming asset.

Yet many SOCs retain such detections indefinitely.

Not because they produce value — but because no one measures them economically.

The Detection Portfolio Matrix

To operationalize this, we introduce a 2×2 model:

	High Yield	Low Yield
High Volume	Core Assets	Noise Risk
Low Volume	Precision Signals	Monitoring Candidates

Core Assets

High-volume, high-yield detections. These are foundational. Optimize, maintain, and defend them.

Noise Risk

High-volume, low-yield detections. These are capital drains. Redesign or retire.

Precision Signals

Low-volume, high-yield detections. These are strategic. Stress test for blind spots and ensure telemetry quality.

Monitoring Candidates

Low-volume, low-yield. Watch for drift or evolving relevance.

This model forces discipline.

Before building a new detection, ask:

What detection cluster does this belong to?
What is its expected yield?
What is its expected investigation cost?
What is its marginal ROI?

Detection engineering becomes intentional investment, not reactive expansion.

Implementation: Transitioning from Volume to Yield

This transformation does not require new tooling. It requires new categorization and measurement discipline.

Step 1 – Categorize Detection Families

Group alerts by logical family (identity misuse, endpoint anomaly, privilege escalation, etc.). Avoid measuring at individual rule granularity — measure at strategic clusters.

Step 2 – Attach Investigation Cost

Estimate average analyst time per alert category. Even approximations create clarity.

Time is the true currency of the SOC.

Step 3 – Calculate Yield

For each family:

Signal Yield Rate
Severity-weighted yield
Time-adjusted yield

Step 4 – Plot the Yield Curve

Identify:

Where volume produces diminishing returns
Which families dominate investigative capacity
Where engineering effort should concentrate

Step 5 – Reallocate Engineering Investment

Focus on:

Improving high-impact detections
Eliminating flat-return clusters
Re-tuning threshold-heavy anomaly models
Investing in telemetry that increases high-yield signal density

This is not about eliminating alerts.

It is about increasing return per alert.

A Real-World Application Example

Consider a SOC performing yield analysis.

They discover:

Credential misuse detection: 18% yield
Endpoint anomaly detection: 0.4% yield
Endpoint anomaly consumes 40% of analyst time

Under a volume-centric model, anomaly detection appears productive because it generates activity.

Under a yield model, it is a capital drain.

The decision:

Re-engineer anomaly thresholds
Improve identity telemetry depth
Increase focus on high-yield credential signals

Six months later:

Confirmed incident discovery increases
Analyst workload becomes strategically focused
Weighted CVI decreases
Burnout declines

The SOC didn’t reduce alerts blindly.

It increased signal density.

Third-Order Consequences

When SOCs optimize for signal yield instead of alert volume, several systemic changes occur:

Board reporting becomes defensible.
You can quantify risk reduction efficiency.
Budget conversations mature.
Funding becomes tied to economic return, not fear narratives.
“Alert theater” declines.
Activity is no longer mistaken for effectiveness.
Detection quality compounds.
Engineering effort concentrates where marginal ROI is highest.

Over time, this shifts the SOC from reactive operations to disciplined capital allocation.

Security becomes measurable in economic terms.

And that changes everything.

The Larger Shift

We are entering an era where AI will dramatically expand alert generation capacity. Detection logic will become cheaper to create. Telemetry will grow.

If we continue to measure success by volume reduction alone, we will drown more efficiently.

Signal yield is the architectural evolution.

It creates a common language between:

SOC leaders
CISOs
Finance
Boards

And it elevates detection engineering from operational tuning to strategic asset management.

Alert reduction was Phase One.

Signal economics is Phase Two.

The SOC of the future will not be measured by how quiet it is.

It will be measured by how much validated risk reduction it produces per unit of capital consumed.

That is the metric that survives scrutiny.

And it is the metric worth building toward.

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

How to Cut SOC Alert Volume 40–60% Without Increasing Breach Risk

Posted on February 23, 2026 by Brent Huston

If you’re running a SOC in a 1,000–20,000 employee organization, you don’t have an alert problem.

You have an alert economics problem.

When I talk to CISOs and SOC Directors operating hybrid environments with SIEM and SOAR already deployed, the numbers are depressingly consistent:

10,000–100,000 alerts per day
MTTR under scrutiny
Containment time tracked weekly
Analyst attrition quietly rising
Budget flat (or worse)

And then the question:

“How do we handle more alerts without missing the big one?”

Wrong question.

The right question is:

“Which alerts should not exist?”

This article is a practical, defensible way to reduce alert volume by 40–60% (directionally, based on industry norms) without increasing breach risk. It assumes a hybrid cloud environment with a functioning SIEM and SOAR platform already in place.

This is not theory. This is operating discipline.

AILogAnalyst

First: Define “Without Increasing Breach Risk”

Before you touch a rule, define your safety boundary.

For this exercise, “no increased breach risk” means:

No statistically meaningful increase in missed high-severity incidents
No degradation in detection of your top-impact scenarios
No silent blind spots introduced by automation

That implies instrumentation.

You will track:

Leading metrics

Alerts per analyst per shift
% alerts auto-enriched before triage
Escalation rate (alert → case)
Median time-to-triage

Lagging metrics

MTTR
Incident containment time
Confirmed incident miss rate (via backtesting + sampling)

If you can’t measure signal quality, you will default back to counting volume.

And volume is the wrong KPI.

The Structural Problem Most SOCs Ignore

Alert fatigue is usually not a staffing problem.

It’s structural.

Let’s deconstruct it from first principles.

Alert creation =

Detection rule quality × Data fidelity × Context availability × Threshold design

Alert handling =

Triage logic × Skill level × Escalation clarity × Tool ergonomics

Burnout =

Alert volume × Repetition × Low agency × Poor feedback loops

Most organizations optimize alert handling.

Very few optimize alert creation.

That’s why AI copilots layered on top of noisy systems rarely deliver the ROI promised. They help analysts swim faster — but the flood never stops.

Step 1: Do a Real Pareto Analysis (Not a Dashboard Screenshot)

Pull 90 days of alert data.

Per rule (or detection family), calculate:

Total alert volume
% of total volume
Escalations
Confirmed incidents
Escalation rate (cases ÷ alerts)
Incident yield (incidents ÷ alerts)

What you will likely find:

A small subset of rules generate a disproportionate amount of alerts with negligible incident yield.

Those are your leverage points.

A conservative starting threshold I’ve seen work repeatedly:

<1% escalation rate
Zero confirmed incidents in 6 months
Material volume impact

Those rules go into review.

Not deleted immediately. Reviewed.

Step 2: Eliminate Structural Noise

This is where 40–60% reduction becomes realistic.

1. Kill Duplicate Logic

Multiple tools firing on the same behavior.
Multiple rules detecting the same pattern.
Multiple alerts per entity per time window.

Deduplicate at the correlation layer — not just in the UI.

One behavior. One alert. One case.

2. Convert “Spam Rules” into Aggregated Signals

If a vulnerability scanner fires 5,000 times a day, you do not need 5,000 alerts.

You need one:

“Expected scanner activity observed.”

Or, more interestingly:

“Scanner activity observed from non-approved host.”

Aggregation preserves visibility while eliminating interruption.

3. Introduce Tier 0 (Telemetry-Only)

This is the most underused lever in SOC design.

Not every signal deserves to interrupt a human.

Define:

T0 – Telemetry only (logged, searchable, no alert)
T1 – Grouped alert (one per entity per window)
T2 – Analyst interrupt
T3 – Auto-containment candidate

Converting low-confidence detections into T0 telemetry can remove massive volume without losing investigative data.

You are not deleting signal.

You are removing interruption.

Step 3: Move Enrichment Before Alert Creation

Most SOCs enrich after alert creation.

That’s backward.

If context changes whether an alert should exist, enrichment belongs before the alert.

Minimum viable enrichment that actually changes triage outcomes:

Asset criticality
Identity privilege level
Known-good infrastructure lists
Recent vulnerability context
Entity behavior history

Decision sketch:

If high-impact behavior
AND privileged identity or critical asset
AND contextual risk indicators present
→ Create T2 alert

Else if repetitive behavior with incomplete context
→ Grouped T1 alert

Else
→ T0 telemetry

This is where AI can be valuable.

Not as an auto-closer.

As a pre-alert context aggregator and risk scorer.

If AI is applied after alert creation, you are optimizing cost you didn’t need to incur.

Step 4: Establish a Detection “Kill Board”

Rules should be treated like production code.

They have operational cost. They require ownership.

Standing governance model:

Detection Lead – rule quality
SOC Manager – workflow impact
IR Lead – breach risk validation
CISO – risk acceptance authority

Decision rubric:

Does this rule map to a real, high-impact scenario?
Is its incident yield acceptable relative to volume?
Would enrichment materially improve precision?
Is it duplicative elsewhere?

Rules with zero incident value over defined periods should require justification.

Visibility is not the same as interruption.

Compliance logging can coexist with fewer alerts.

Step 5: Automation — With Guardrails

Automation is not the first lever.

It is the multiplier.

Safe automation patterns:

Context enrichment
Intelligent routing
Alert grouping
Reversible containment with approval gates

Dangerous automation patterns:

Permanent suppression without expiry
Auto-closure without sampling
Logic changes without audit trail

Guardrails I consider non-negotiable:

Suppression TTL (30–90 days)
Random sampling of suppressed alerts (0.5–2%)
Quarterly breach-backtesting
Full automation decision logging

Noise today can become weak signal tomorrow.

Design for second-order effects.

Why AI Fails in Noisy SOCs

If alert volume doesn’t change, analyst workload doesn’t change.

AI layered on broken workflows becomes a coping mechanism, not a transformation.

The highest ROI AI use case in mature SOCs is:

Pre-alert enrichment + risk scoring.

Not post-alert summarization.

Redesign alert economics first.

Then scale AI.

What 40–60% Reduction Actually Looks Like

In environments with:

Default SIEM thresholds
Redundant telemetry
No escalation-rate filtering
No Tier 0
No suppression expiry
No detection governance loop

A 40–60% alert reduction is directionally achievable without loss of high-severity coverage.

The exact number depends on detection maturity.

The risk comes not from elimination.

The risk comes from elimination without measurement.

Two-Week Quick Start

If you need results before the next KPI review:

Export 90 days of alerts.
Compute escalation rate per rule.
Identify bottom 20% of signal drivers.
Convene rule rationalization session.
Pilot suppression or grouping with TTL.
Publish signal-to-noise ratio as a KPI alongside MTTR.

Shift the conversation from:

“How do we close more alerts?”

To:

“Why does this alert exist?”

The Core Shift

SOC overload is not caused by insufficient analyst effort.

It is caused by incentive systems that reward detection coverage over detection precision.

If your success metric is number of detections deployed, you will generate endless noise.

If your success metric is signal-to-noise ratio, the system corrects itself.

You don’t fix alert fatigue by hiring faster triage.

You fix it by designing alerts to be expensive.

And when alerts are expensive, they become rare.

And when they are rare, they matter.

That’s the design goal.

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

Beyond Zero Trust: Identity-First Security Strategies That Actually Reduce Risk in 2026

Posted on February 18, 2026 by Brent Huston

A Breach That Didn’t Break In — It Logged In

The email looked routine.

A finance employee received a vendor payment request — well-written, contextually accurate, referencing an actual project. Nothing screamed “phish.” Attached was a short voice note from the CFO explaining the urgency.

The voice sounded right. The cadence, the phrasing — even the subtle impatience.

Moments later, a multi-factor authentication (MFA) prompt appeared. The employee approved it without thinking. They had approved dozens that week. Habit is powerful.

The breach didn’t bypass the firewall.
It didn’t exploit a zero-day vulnerability.
It didn’t even evade detection.

It bypassed identity confidence.

By the time the security team noticed anomalous financial transfers, the attacker had already authenticated, escalated privileges, and pivoted laterally — all using valid credentials.

In 2026, attackers aren’t breaking in.

They’re logging in.

And that reality demands a shift in how we think about security architecture. Zero Trust was a necessary evolution. But in many organizations, it’s stalled at the network layer. Meanwhile, identity has quietly become the primary control plane — and the primary attack surface.

If identity is where trust decisions happen, then identity is where risk must be engineered out.

A hacker is seated in front of a computer fingers poised over the keyboard They are ready to break into a system and gain access to sensitive information 6466041

Zero Trust Isn’t Enough Anymore

Zero Trust began as a powerful principle: “Never trust, always verify.” It challenged perimeter-centric thinking and encouraged segmentation, least privilege, and continuous validation.

But somewhere along the way, it became a marketing label.

Many implementations focus heavily on:

Network micro-segmentation
VPN replacement
Device posture checks
SASE rollouts

All valuable. None sufficient.

Because identity remains the weakest link.

AI Has Changed the Identity Battlefield

Attackers now leverage AI to:

Craft highly personalized spear phishing emails
Generate convincing deepfake audio and video impersonations
Launch MFA fatigue campaigns at scale
Automate credential stuffing with adaptive logic

The tools available to adversaries have industrialized social engineering.

Push-based MFA, once considered strong protection, is now routinely abused through prompt bombing. Deepfake impersonation erodes human intuition. Credential reuse remains rampant.

Perimeter thinking has died.
Device-centric thinking is incomplete.
Identity is now the primary control plane.

If identity is the new perimeter, it must be treated like critical infrastructure — not a checkbox configuration in your IAM console.

The Identity-First Security Framework

An identity-first strategy doesn’t abandon Zero Trust. It operationalizes it — with identity at the center of risk reduction.

Below are five pillars that move identity from access management to risk engineering.

Pillar 1: Reduce the Identity Attack Surface

A simple Pareto principle applies:

20% of identities create 80% of risk.

Privileged users. Service accounts. Automation tokens. Executive access. CI/CD credentials.

The first step isn’t detection. It’s reduction.

Actions

Inventory all identities — human and machine
Eliminate dormant accounts
Reduce standing privileges
Enforce just-in-time (JIT) access for elevated roles

Standing privilege is latent risk. Every persistent admin account is a pre-approved breach path.

Metrics That Matter

Percentage of privileged accounts
Average privilege duration
Dormant account count
Privileged access review frequency

Organizations that aggressively reduce identity sprawl see measurable decreases in lateral movement potential.

Reducing exposure is step one.
Validating behavior is step two.

Pillar 2: Continuous Identity Verification — Not Just MFA

MFA is necessary. It is no longer sufficient.

Push-based MFA fatigue attacks are common. Static authentication events assume trust after login. Attackers exploit both.

We must shift from event-based authentication to session-based validation.

Move Beyond:

Blind push approvals
Static login checks
Binary allow/deny thinking

Add:

Risk-based authentication
Device posture validation
Behavioral biometrics
Continuous session monitoring

Attackers use AI to simulate legitimacy.
Defenders must use AI to detect deviation.

Useful Metrics

MFA approval anomaly rate
Impossible travel detections
Session risk score trends
High-risk login percentage

Authentication should not be a moment. It should be a monitored process.

Pillar 3: Identity Telemetry & Behavioral Baselines

First-principles thinking:
What is compromise?

It is behavior deviation.

A legitimate user logging in from a new country at 3:00 a.m. and accessing sensitive financial systems may have valid credentials — but invalid behavior.

Implementation Steps

Build per-role behavioral baselines
Track privilege escalation attempts
Integrate IAM logs into SOC workflows
Correlate identity data with endpoint and cloud telemetry

Second-order thinking matters here.

More alerts without tuning leads to burnout.

Identity alerts must be high-confidence. Behavioral models must understand role context, not just user anomalies.

Security teams should focus on detecting intent signals — not just login events.

Pillar 4: Machine Identity Governance

Machine identities often outnumber human identities in cloud-native environments.

Consider:

Service accounts
API tokens
Certificates
CI/CD pipeline credentials
Container workload identities

AI-powered attackers increasingly target automation keys. They know that compromising a service account can provide persistent, stealthy access.

Critical Actions

Automatically rotate secrets
Shorten token lifetimes
Continuously scan repositories for hardcoded credentials
Enforce workload identity controls

Key Metrics

Average token lifespan
Hardcoded secret discovery rate
Machine identity inventory completeness
Unused service account count

Machine identities do not get tired. They also do not question unusual requests.

That makes them both powerful and dangerous.

Pillar 5: Identity Incident Response Playbooks

Identity compromise spreads faster than traditional breaches because authentication grants implicit trust.

Incident response must evolve accordingly.

Include in Playbooks:

Immediate token invalidation
Automated session termination
Privilege rollback
Identity forensics logging
Rapid behavioral reassessment

Identity Maturity Model

Level	Capability
Level 1	MFA + Basic IAM
Level 2	JIT Access + Risk-based authentication
Level 3	Behavioral detection + Machine identity governance
Level 4	Autonomous identity containment

The future state is not manual triage.

It is autonomous identity containment.

Implementation Roadmap

Transformation does not require a multi-year overhaul. It requires disciplined sequencing.

First 30 Days

Conduct a full identity inventory audit
Launch a privilege reduction sprint
Review MFA configurations and eliminate push-only dependencies
Identify dormant and orphaned accounts

Immediate wins come from subtraction.

First 90 Days

Deploy risk-based authentication policies
Integrate identity telemetry into SOC workflows
Begin machine identity governance initiatives
Establish behavioral baselines for high-risk roles

Security operations and IAM teams must collaborate here.

Six-Month Horizon

Implement behavioral AI modeling
Automate session risk scoring
Deploy automated identity containment workflows
Establish executive reporting on identity risk metrics

Identity becomes measurable. Measurable becomes manageable.

Real-World Examples

Example 1: Privilege Reduction

One enterprise reduced privileged accounts by 42%. The measurable result: significant reduction in lateral movement pathways and faster containment during simulated breach exercises.

Example 2: MFA Fatigue Prevention

A financial services firm detected abnormal MFA approval timing patterns. Session anomaly detection flagged behavior inconsistent with historical norms. The attack was stopped before funds were transferred.

The lesson: behavior, not just credentials, determines legitimacy.

Measurable Outcomes

Identity Control	Risk Reduced	Measurement Method
JIT Privilege	Lateral movement	Privilege duration logs
Risk-based MFA	Phishing success	Approval anomaly rate
Token rotation	Credential abuse	Token age metrics
Behavioral baselines	Account takeover	Session deviation scores
Machine identity inventory	Automation abuse	Service account audits

Security leaders must shift from tool counts to risk-reduction metrics.

Identity Is the New Control Plane

Attackers scale with AI.

They automate reconnaissance. They generate deepfake executives. They weaponize credentials at industrial scale.

Defenders must scale identity intelligence.

In 2026, the organizations that win will not be those with the most tools. They will be those who understand that identity is infrastructure.

Firewalls inspect traffic.
Endpoints enforce policy.
Identity determines authority.

And authority is what attackers want.

Zero Trust was the beginning. Identity-first security is the evolution.

The question is no longer whether your users are inside the perimeter.

The question is whether your identity architecture assumes breach — and contains it automatically.

Info & Help: Advancing Your Identity Strategy

Identity-first security is not a product deployment. It is an operational discipline.

If your organization is:

Struggling with privilege sprawl
Experiencing MFA fatigue attempts
Concerned about AI-driven impersonation
Lacking visibility into machine identities
Unsure how to measure identity risk

The team at MicroSolved, Inc. can help.

For over three decades, MicroSolved has assisted enterprises, financial institutions, healthcare providers, and critical infrastructure organizations in strengthening identity governance, incident response readiness, and security operations maturity.

Our services include:

Identity risk assessments
Privileged access reviews
IAM architecture design
SOC integration and telemetry tuning
Incident response planning and tabletop exercises

If identity is your new control plane, it deserves engineering rigor.

Reach out to MicroSolved to discuss how to reduce measurable identity risk — not just deploy another control.

Security is no longer about keeping attackers out.

It’s about making sure that when they log in, they don’t get far.

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.

The Hidden Cost of Compliance: Why “Checkbox Security” Fails Modern Organizations

Posted on February 9, 2026 by Brent Huston

In today’s threat landscape, simply “checking the boxes” isn’t enough. Organizations invest enormous time and money to satisfy regulatory frameworks like PCI DSS, HIPAA, ISO 27001, GDPR, and NIS2—but too often they stop there. The result? A false sense of cybersecurity readiness that leaves critical vulnerabilities unaddressed and attackers unchallenged.

Compliance should be a foundation—not a finish line. Let’s unpack why checkbox compliance consistently fails modern enterprises and how forward-looking security leaders can close the gap with truly risk-based strategies.

Compliance vs. Security: Two Sides of the Same Coin?

Compliance and security are related—but they are emphatically not the same thing.

Compliance is about adherence to external mandates, standards, and audits.
Security is about reducing risk, defending against threats, and protecting data, systems, and business continuity.

Expecting compliance alone to prevent breaches is like believing that owning a fire extinguisher will stop every fire. The checklists in PCI DSS, HIPAA, or ISO standards are minimum controls designed to reduce loss—not exhaustive defenses against every attacker tactic.

“Compliance is not security.” — Security thought leaders have said this many times, and it rings true as organizations equate audit success with risk reduction.

Checkbox Security: Why It Fails

A compliance mindset often devolves into a checkbox mentality—complete documentation, filled-in forms, and green lights from auditors. But this approach contains several fundamental flaws:

1. Compliance Standards Lag Behind Evolving Threats

Most regulatory frameworks are reactive, built around known threats and past incidents. Cyber threats evolve constantly; sticking strictly to compliance means protecting against yesterday’s risks, not today’s or tomorrow’s.

2. Checklists Lack Contextual Risk Prioritization

Compliance is binary—yes/no answers. But not all controls have equal impact. A firewall might be present (box ticked), yet the organization might ignore the most actively exploited vulnerabilities like unpatched software or phishing risk.

3. Audit Success Doesn’t Equal Real-World Security

Auditors assess documentation and evidence of controls; they rarely test adversarial resilience. A compliant organization can still suffer devastating breaches because compliance assessments aren’t adversarial and don’t simulate real attacks.

Real-World Proof: Breaches Despite Compliance

Arguments against checkbox compliance sound theoretical—until you look at real breaches. Examples of organizations meeting compliance requirements yet being breached are widespread:

PCI DSS Compliance Breaches

Despite strict PCI requirements for safeguarding cardholder data, many breached organizations were technically compliant at the time of compromise. Researchers even note that no fully compliant organization examined was breach-free, and compliance fines or gaps didn’t prevent attackers from exploiting weak links in implementation.

Healthcare Data Risks Despite HIPAA

Even with stringent HIPAA requirements, healthcare breaches are rampant. Reports show thousands of HIPAA violations and data exposures annually, demonstrating that merely having compliance frameworks doesn’t stop attackers.

The Hidden Costs of Compliance-Only Security

When organizations chase compliance without aligning to deeper risk strategy, the costs go far beyond audit efforts.

1. Opportunity Cost

Security teams spend incredible hours on documentation, standard operating procedure updates, and audit response—hours that could otherwise support vulnerability remediation, threat hunting, and continuous monitoring.

2. False Sense of Security

Executives and boards often equate compliance with safety. But compliance doesn’t guarantee resilience. That false confidence can delay investments in deeper controls until it’s too late.

3. Breach Fallout

When conformity fails, consequences extend far beyond compliance fines. Reputational damage, customer churn, supply chain impacts, and board-level accountability can dwarf regulatory penalties.

Beyond Checkboxes: What Modern Security Needs

To turn compliance from checkbox security into business-aligned risk reduction, organizations should consider the following advanced practices:

1. Continuous Risk Measurement

Shift from periodic compliance assessments to continuous risk evaluation tied to real business outcomes. Tools that quantify risk exposure in financial and operational terms help prioritize investments where they matter most.

2. Threat Modeling & Adversary Emulation

Map attacker tactics relevant to your business context, then test controls against them. Frameworks like MITRE ATT&CK can help organizations think like attackers, not auditors.

3. Metrics That Measure Security Effectiveness

Move away from compliance metrics (“% of controls implemented”) to outcome metrics (“time to detect/respond to threats,” “reduction in high-risk exposures,” etc.). These demonstrate real improvements versus checkbox completion.

4. Integration of Security and Compliance

Security leaders should leverage compliance requirements as part of broader risk strategy—not substitutes. GRC (Governance, Risk, and Compliance) platforms can tie compliance evidence to risk dashboards for a unified view.

How MicroSolved Can Help

At MicroSolved, we’ve seen these pitfalls firsthand. Organizations often approach compliance automation or external consultants expecting silver bullets—but without continuous risk measurement and business context, security controls still fall short.

MicroSolved’s approach focuses on:

Risk-based security program development
Ongoing threat modeling and adversary testing
Metrics and dashboards tied to business outcomes
Integration of compliance frameworks like PCI, HIPAA, ISO 27001 with enterprise risk strategies

If your team is struggling to move beyond checkbox compliance, we’re here to help align your cybersecurity program with real-world risk reduction—not just regulatory requirements.

➡️ Learn more about how MicroSolved can help bridge the gap between compliance and true security effectiveness.

Conclusion: Compliance Is the Floor, Not the Ceiling

Regulatory frameworks remain essential—they set the minimum expectations for protecting data and privacy. But in a world of rapidly evolving threats, compliance alone can’t be the endpoint of your cybersecurity efforts.

Checkbox security gives boards comfort, but attackers don’t check boxes—they exploit gaps.

Security leaders who integrate risk measurement, continuous validation, and business alignment into their compliance programs not only strengthen defenses—they elevate security into a source of competitive advantage.

* AI tools were used as a research assistant for this content, but human moderation and writing are also included. The included images are AI-generated.