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.

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.

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.

Defending Small Credit Unions in the Age of AI-Driven Synthetic Fraud

Posted on February 2, 2026 by Brent Huston

We’ve seen fraud evolve before. We’ve weathered phishing, credential stuffing, card skimming, and social engineering waves—but what’s coming next makes all of that look like amateur hour. According to Experian and recent security forecasting, we’re entering a new fraud era. One where AI-driven agents operate autonomously, build convincing synthetic identities at scale, and mount adaptive, shape-shifting attacks that traditional defenses can’t keep up with.

For small credit unions and community banks, this isn’t a hypothetical future—it’s an urgent call to action.

The Rise of Synthetic Realities

Criminals are early adopters of innovation. Always have been. But now, 80% of observed autonomous AI agent use in cyberattacks is originating from criminal groups. These aren’t script kiddies with GPT wrappers—these are fully autonomous fraud agents, built to execute entire attack chains from data harvesting to cash-out, all without human intervention.

They’re using the vast stores of breached personal data to forge synthetic identities that are indistinguishable from real customers. The result? Hyper-personalized phishing, credential takeovers, and fraudulent accounts that slip through onboarding and authentication checks like ghosts.

Worse yet, quantum computing is looming. And with it, the shift from “break encryption” to “harvest now, decrypt later” is already in motion. That means data stolen today—unencrypted or encrypted with current algorithms—could be compromised retroactively within a decade or less.

So what can small institutions do? You don’t have the budget of a multinational bank, but that doesn’t mean you’re defenseless.

Three Moves Every Credit Union Must Make Now

1. Harden Identity and Access Controls—Everywhere

This isn’t just about enforcing MFA anymore. It’s about enforcing phishing-resistant MFA. That means FIDO2, passkeys, hardware tokens—methods that don’t rely on SMS or email, which are easily phished or intercepted.

Also critical: rethink your workflows around high-risk actions. Wire transfers, account takeovers, login recovery flows—all of these should have multi-layered checks that include risk scoring, device fingerprinting, and behavioral cues.

And don’t stop at customers. Internal systems used by staff and contractors are equally vulnerable. Compromising a teller or loan officer’s account could give attackers access to systems that trust them implicitly.

2. Tune Your Own Data for AI-Driven Defense

You don’t need a seven-figure fraud platform to start detecting anomalies. Use what you already have: login logs, device info, transaction patterns, location data. There are open-source and affordable ML tools that can help you baseline normal activity and alert on deviations.

But even better—don’t fight alone. Join information-sharing networks like FS-ISAC, InfraGard, or sector-specific fraud intel circles. The earlier you see a new AI phishing campaign or evolving shape-shifting malware variant, the better chance you have to stop it before it hits your members.

3. Start Your “Future Threats” Roadmap Today

You can’t wait until quantum breaks RSA to think about your crypto. Inventory your “crown jewel” data—SSNs, account histories, loan documents—and start classifying which of that needs to be protected even after it’s been stolen. Because if attackers are harvesting now to decrypt later, you’re already in the game whether you like it or not.

At the same time, tabletop exercises should evolve. No more pretending ransomware is the worst-case. Simulate a synthetic ID scam that drains multiple accounts. Roleplay a deepfake CEO fraud call to your CFO. Put AI-enabled fraud on the whiteboard and walk your board through the response.

Final Thoughts: Small Can Still Mean Resilient

Small institutions often pride themselves on their close member relationships and nimbleness. That’s a strength. You can spot strange behavior sooner. You can move faster than a big bank on policy changes. And you can build security into your culture—where it belongs.

But you must act deliberately. AI isn’t waiting, and quantum isn’t slowing down. The criminals have already adapted. It’s our turn.

Let’s not be the last to see the fraud that’s already here.

* 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.

AI in Cyber Defense: What Works Today vs. What’s Hype

Posted on January 28, 2026 by Brent Huston

Practical Deployment Paths

Artificial Intelligence is no longer a futuristic buzzword in cybersecurity — it’s here, and defenders are being pressured on all sides: vendors pushing “AI‑enabled everything,” adversaries weaponizing generative models, and security teams trying to sort signal from noise. But the truth matters: mature security teams need clarity, realism, and practicable steps, not marketing claims or theoretical whitepapers that never leave the lab.

The Pain Point: Noise > Signal

Security teams are drowning in bold AI vendor claims, inflated promises of autonomous SOCs, and feature lists that promise effortless detection, response, and orchestration. Yet:

Budgets are tight.
Societies face increasing threats.
Teams lack measurable ROI from expensive, under‑deployed proof‑of‑concepts.

What’s missing is a clear taxonomy of what actually works today — and how to implement it in a way that yields measurable value, with metrics security leaders can trust.

AISecImage

The Reality Check: AI Works — But Not Magically

It’s useful to start with a grounding observation: AI isn’t a magic wand.
When applied properly, it does elevate security outcomes, but only with purposeful integration into existing workflows.

Across the industry, practical AI applications today fall into a few consistent categories where benefits are real and demonstrable:

1. Detection and Triage

AI and machine learning are excellent at analyzing massive datasets to identify patterns and anomalies across logs, endpoint telemetry, and network traffic — far outperforming manual review at scale. This reduces alert noise and helps prioritize real threats.

Practical deployment path:

Integrate AI‑enhanced analytics into your SIEM/XDR.
Focus first on anomaly detection and false‑positive reduction — not instant response automation.

Success metrics to track:

False positive rate reduction
Mean Time to Detect (MTTD)

2. Automated Triage & Enrichment

AI can enrich alerts with contextual data (asset criticality, identity context, threat intelligence) and triage them so analysts spend time on real incidents.

Practical deployment path:

Connect your AI engine to log sources and enrichment feeds.
Start with automated triage and enrichment before automation of response.

Success metrics to track:

Alerts escalated vs alerts suppressed
Analyst workload reduction

3. Accelerated Incident Response Workflows

AI can power playbooks that automate parts of incident handling — not the entire response — such as containment, enrichment, or scripted remediation tasks.

Practical deployment path:

Build modular SOAR playbooks that call AI models for specific tasks, not full control.
Always keep a human‑in‑the‑loop for high‑impact decisions.

Success metrics to track:

Reduced Mean Time to Respond (MTTR)
Accuracy of automated actions

What’s Hype (or Premature)?

While some applications are working today, others are still aspirational or speculative:

❌ Fully Autonomous SOCs

Vendor claims of SOC teams run entirely by AI that needs minimal human oversight are overblown at present. AI excels at assistance, not autonomous defense decision‑making without human‑in‑the‑loop review.

❌ Predictive AI That “Anticipates All Attacks”

There are promising approaches in predictive analytics, but true prediction of unknown attacks with high fidelity is still research‑oriented. Real‑world deployments rarely provide reliable predictive control without heavy contextual tuning.

❌ AI Agents With Full Control Over Remediations

Agentic AI — systems that take initiative across environments — are an exciting frontier, but their use in live environments remains early and risk‑laden. Expectations about autonomous agents running response workflows without strict guardrails are unrealistic (and risky).

A Practical AI Use Case Taxonomy

A clear taxonomy helps differentiate today’s practical uses from tomorrow’s hype. Here’s a simple breakdown:

Category	What Works Today	Implementation Maturity
Detection	Anomaly/Pattern detection in logs & network	Mature
Triage & Enrichment	Alert prioritization & context enrichment	Mature
Automation Assistance	Scripted, human‑supervised response tasks	Growing
Predictive Intelligence	Early insights, threat trend forecasting	Emerging
Autonomous Defense Agents	Research & controlled pilot only	Experimental

Deployment Playbooks for 3 Practical Use Cases

1️⃣ AI‑Enhanced Log Triage

Objective: Reduce analyst time spent chasing false positives.
Steps:
1. Integrate machine learning models into SIEM/XDR.
2. Tune models on historical data.
3. Establish feedback loops so analysts refine model behaviors.
Key metric: ROC curve for alert accuracy over time.

2️⃣ Phishing Detection & Response

Objective: Catch sophisticated phishing that signature engines miss.
Steps:
1. Deploy NLP‑based scanning on inbound email streams.
2. Integrate with threat intelligence and URL reputation sources.
3. Automate quarantine actions with human review.
Key metric: Reduction in phishing click‑throughs or simulated phishing failure rates.

3️⃣ SOAR‑Augmented Incident Response

Objective: Speed incident handling with reliable automation segments.
Steps:
1. Define response playbooks for containment and enrichment.
2. Integrate AI for contextual enrichment and prioritization.
3. Ensure manual checkpoints before broad remediation actions.
Key metric: MTTR before/after SOAR‑AI implementation.

Success Metrics That Actually Matter

To beat the hype, track metrics that tie back to business outcomes, not vendor marketing claims:

MTTD (Mean Time to Detect)
MTTR (Mean Time to Respond)
False Positive/Negative Rates
Analyst Productivity Gains
Time Saved in Triage & Enrichment

Lessons from AI Deployment Failures

Across the industry, failed AI deployments often stem from:

Poor data quality: Garbage in, garbage out. AI needs clean, normalized, enriched data.
Lack of guardrails: Deploying AI without human checkpoints breeds costly mistakes.
Ambiguous success criteria: Projects without business‑aligned ROI metrics rarely survive.

Conclusion: AI Is an Accelerator, Not a Replacement

AI isn’t a threat to jobs — it’s a force multiplier when responsibly integrated. Teams that succeed treat AI as a partner in routine tasks, not an oracle or autonomous commander. With well‑scoped deployment paths, clear success metrics, and human‑in‑the‑loop guardrails, AI can deliver real, measurable benefits today — even as the field continues to evolve.

* 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.

Antifragility in the Age of Cyber Extremistan

Posted on January 14, 2026 by Brent Huston

Why Building Cybersecurity Like the Human Immune System Is the Only Strategy That Survives the Unknown

Unnamed 4

We don’t live in “Mediocristan” anymore.

In the controlled world of Gaussian curves and predictable outcomes, most security strategies make sense—if you’re still living in the realm where human height and blood pressure are your biggest threats. But for cybersecurity practitioners, the real world looks more like “Extremistan”—the place where Black Swan events dominate, where a single breach can wipe out decades of effort, and where average behavior is not just irrelevant, it’s dangerously misleading.

That’s the world Nassim Taleb described in The Black Swan, and it’s the reality we live in every day as defenders of digital infrastructure.

And if you’re using traditional models to manage cyber risk in this world, you’re probably optimizing for failure.

From Robust to Antifragile: Why Survival Isn’t Enough

Taleb coined the term antifragile to describe systems that don’t just resist chaos—they improve because of it. It’s the difference between a glass that doesn’t break and a muscle that gets stronger after lifting heavy weight. Most security programs are designed to be robust—resilient under stress. But that’s not enough. Resilience still assumes a limit. Once you pass the red line, you break.

To thrive in Extremistan, we need to design systems that learn from stress, that benefit from volatility, and that get stronger every time they get punched in the face.

1. Security by Subtraction (Via Negativa)

In medicine, there’s a term called iatrogenics—harm caused by the treatment itself. Sound familiar? That’s what happens when a security stack becomes so bloated with overlapping agents, dashboards, and tools that it becomes its own attack surface.

Antifragile security starts with subtraction:

Decommission Legacy: Every unmonitored web server from 2009 you forgot about is a potential ruin event.
Minimize Privilege: If your domain admin group has more people than your bowling team, you’re in trouble.
Simplify, Aggressively: Complexity is fragility disguised as maturity.

Less isn’t just more—it’s safer.

2. Controlled Stressors: Hormesis for Systems

An immune system kept in a bubble weakens. One that’s constantly challenged becomes elite. The same goes for cyber defenses.

Red Teams as Immune Response Training: Stop treating red teams as adversaries. They’re your vaccine.
Chaos Engineering: Don’t just test recovery—induce failure. Intentionally break things. Break them often. Learn faster than your adversaries.
Study the Misses: Every alert that almost mattered is gold dust. Train on it.

This isn’t about drills. It’s about muscle memory.

3. The Barbell Strategy: Secure Boring + Wild Bets

One of Taleb’s more underappreciated ideas is the barbell strategy: extreme conservatism on one end, high-risk/high-reward exploration on the other. Nothing in the middle.

90%: Lock down the basics. IG1 controls. Patching. Backups. Privilege minimization. The boring stuff that wins wars.
10%: Invest in weird, bleeding-edge experiments. Behavioral traps. Decoy data. Offensive ML. This is your lab.

Never bet on “average” security tools. That’s how you end up with a little risk everywhere—and a big hole somewhere you didn’t expect.

4. Skin in the Game: Incentives That Matter

When the people making decisions don’t bear the cost of failure, systems rot from within.

Vendors Must Own Risk: If your EDR vendor can disclaim all liability for failure, they’ve got no skin in your game.
On-Call Developers: If they wrote the code, they stay up with it. The best SLAs are fear and pride.
Risk-Based Compensation: CISOs must have financial incentives tied to post-incident impact, not checkbox compliance.

Fragility flourishes in environments where blame is diffuse and consequences are someone else’s problem.

5. Tail Risk and the Absorbing Barrier

Most CIS frameworks are built to mitigate average risk. But in Extremistan, ruin is what you plan for. The difference? A thousand phishing attempts don’t matter if one spear phish opens the gates.

Design for Blast Radius: Assume breach. Isolate domains. Install circuit breakers in your architecture.
Plan for the Unseen: Run tabletop exercises where the scenario doesn’t exist in your IR plan. If that makes your team uncomfortable, you’re doing it right.
Offline Backups Are Sacred: If they touch the internet, they’re not a backup—they’re bait.

There are no do-overs after ruin.

6. Beware the Turkey Problem

A turkey fed every day believes the butcher loves him—until Thanksgiving. A network with zero incidents for three years might just be a turkey.

Continuous Validation, Not Annual Audits: Trust your controls as much as you test them.
Negative Empiricism: Don’t learn from the shiny success story. Learn from the company that got wrecked.

You are not safe because nothing has happened. You are safe when you have survived what should have killed you.

Closing Thought: Security as Immune System, Not Armor

If you’re still thinking of your security stack as armor—hard shell, resist all—you’re already brittle. Instead, think biology. Think immune system. Think antifragility.

Expose your system to small, survivable threats. Learn from every wound. Build muscle. Be lean, not large. Be hard to kill, not hard to touch.

In a world governed by Extremistan, the best cybersecurity strategy isn’t to avoid failure—it’s to get stronger every time you fail.

Because someday, something will break through. The question is—will you be better afterward, or gone completely?

* 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.

Identity Security Is Now the #1 Attack Vector — and Most Organizations Are Not Architected for It

Posted on December 8, 2025 by Brent Huston

How identity became the new perimeter

In 2025, identity is no longer simply a control at the edge of your network — it is the perimeter. As organizations adopt SaaS‑first strategies, hybrid work, remote access, and cloud identity federation, the traditional notion of network perimeter has collapsed. What remains is the identity layer — and attackers know it.

Today’s breaches often don’t involve malware, brute‑force password cracking, or noisy exploits. Instead, adversaries leverage stolen tokens, hijacked sessions, and compromised identity‑provider (IdP) infrastructure — all while appearing as legitimate users.

SyntheticID

That shift makes identity security not just another checkbox — but the foundation of enterprise defense.

Failure points of modern identity stacks

Even organizations that have deployed defenses like multi‑factor authentication (MFA), single sign‑on (SSO), and conditional access policies often remain vulnerable. Why? Because many identity architectures are:

Overly permissive — long‑lived tokens, excessive scopes, and flat permissioning.
Fragmented — identity data is scattered across IdPs, directories, cloud apps, and shadow IT.
Blind to session risk — session tokens are often unmonitored, allowing token theft and session hijacking to go unnoticed.
Incompatible with modern infrastructure — legacy IAMs often can’t handle dynamic, cloud-native, or hybrid environments.

In short: you can check off MFA, SSO, and PAM, and still be wide open to identity‑based compromise.

Token‑based attack: A walkthrough

Consider this realistic scenario:

An employee logs in using SSO. The browser receives a token (OAuth or session cookie).
A phishing attack — or adversary-in-the-middle (AiTM) — captures that token after the user completes MFA.
The attacker imports the token into their browser and now impersonates the user — bypassing MFA.
The attacker explores internal SaaS tools, installs backdoor OAuth apps, and escalates privileges — all without tripping alarms.

A single stolen token can unlock everything.

Building identity security from first principles

The modern identity stack must be redesigned around the realities of today’s attacks:

Identity is the perimeter — access should flow through hardened, monitored, and policy-enforced IdPs.
Session analytics is a must — don’t just authenticate at login. Monitor behavior continuously throughout the session.
Token lifecycle control — enforce short token lifetimes, minimize scopes, and revoke unused sessions immediately.
Unify the view — consolidate visibility across all human and machine identities, across SaaS and cloud.

How to secure identity for SaaS-first orgs

For SaaS-heavy and hybrid-cloud organizations, these practices are key:

Use a secure, enterprise-grade IdP
Implement phishing-resistant MFA (e.g., hardware keys, passkeys)
Enforce context-aware access policies
Monitor and analyze every identity session in real time
Treat machine identities as equal in risk and value to human users

Blueprint: continuous identity hygiene

Use systems thinking to model identity as an interconnected ecosystem:

Pareto principle — 20% of misconfigurations lead to 80% of breaches.
Inversion — map how you would attack your identity infrastructure.
Compounding — small permissions or weak tokens can escalate rapidly.

Core practices:

Short-lived tokens and ephemeral access
Just-in-time and least privilege permissions
Session monitoring and token revocation pipelines
OAuth and SSO app inventory and control
Unified identity visibility across environments

30‑Day Identity Rationalization Action Plan

Day	Action
1–3	Inventory all identities — human, machine, and service.
4–7	Harden your IdP; audit key management.
8–14	Enforce phishing-resistant MFA organization-wide.
15–18	Apply risk-based access policies.
19–22	Revoke stale or long-lived tokens.
23–26	Deploy session monitoring and anomaly detection.
27–30	Audit and rationalize privileges and unused accounts.

More Information

If you’re unsure where to start, ask these questions:

How many active OAuth grants are in our environment?
Are we monitoring session behavior after login?
When was the last identity privilege audit performed?
Can we detect token theft in real time?

If any of those are difficult to answer — you’re not alone. Most organizations aren’t architected to handle identity as the new perimeter. But the gap between today’s risks and tomorrow’s solutions is closing fast — and the time to address it is now.

Help from MicroSolved, Inc.

At MicroSolved, Inc., we’ve helped organizations evolve their identity security models for more than 30 years. Our experts can:

Audit your current identity architecture and token hygiene
Map identity-related escalation paths
Deploy behavioral identity monitoring and continuous session analytics
Coach your team on modern IAM design principles
Build a 90-day roadmap for secure, unified identity operations

Let’s work together to harden identity before it becomes your organization’s softest target. Contact us at microsolved.com to start your identity security assessment.

References

BankInfoSecurity – “Identity Under Siege: Enterprises Are Feeling It”
SecurityReviewMag – “Identity Security in 2025”
CyberArk – “Lurking Threats in Post-Authentication Sessions”
Kaseya – “What Is Token Theft?”
CrowdStrike – “Identity Attacks in the Wild”
Wing Security – “How to Minimize Identity-Based Attacks in SaaS”
SentinelOne – “Identity Provider Security”
Thales Group – “What Is Identity Security?”
System4u – “Identity Security in 2025: What’s Evolving?”
DoControl – “How to Stop Compromised Account Attacks in SaaS”

* 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.

Racing Ahead of the AI‑Driven Cyber Arms Race

Posted on November 18, 2025 by Brent Huston

Introduction

The cyber-threat landscape is shifting under our feet. Attacker tools powered by artificial intelligence (AI) and generative AI (Gen AI) are accelerating vulnerability discovery and exploitation, outpacing many traditional defence approaches. Organisations that delay adaptation risk being overtaken by adversaries. According to recent reporting, nearly half of organisations identify adversarial Gen AI advances as a top concern. With this blog, I walk through the current threat landscape, spotlight key attack vectors, explore defensive options, examine critical gaps, and propose a roadmap that security leaders should adopt now.

The Landscape: Vulnerabilities, AI Tools, and the Adversary Advantage

Attackers now exploit a converging set of forces: an increasing rate of disclosed vulnerabilities, the wide availability of AI/ML-based tools for crafting attacks, and automation that scales old-school tactics into far greater volume. One report notes 16% of reported incidents involved attackers leveraging AI tools like language or image generation models. Meanwhile, researchers warn that AI-generated threats could make up to 50% of all malware by 2025. Gen AI is now a game-changer for both attackers and defenders.

The sheer pace of vulnerability disclosure also matters. The more pathways available, the more that automation + AI can do damage. Gen AI will be the top driver of cybersecurity in 2024 and beyond—both for malicious actors and defenders.

The baseline for attackers is being elevated. The attacker toolkit is becoming smarter, faster and more scalable. Defenders must keep up — or fall behind.

Specific Threat Vectors to Watch

Deepfakes & Social Engineering

Realistic voice- and video-based deepfakes are no longer novel. They are entering the mainstream of social engineering campaigns. Gen AI enables image and language generation that significantly boosts attacker credibility.

Automated Spear‑Phishing & AI‑Assisted Content Generation

Attackers use Gen AI tools to generate personalised, plausible phishing lures and malicious payloads. LLMs make phishing scalable and more effective, turning what used to take hours into seconds.

Supply Chain & Model/API Exploitation

Third-party AI or ML services introduce new risks—prompt-injection, insecure model APIs, and adversarial data manipulation are all growing threats.

Polymorphic Malware & AI Evasion

AI now drives polymorphic malware capable of real-time mutation, evading traditional static defences. Reports cite that over 75% of phishing campaigns now include this evasion technique.

Defensive Approaches: What’s Working?

AI/ML for Detection and Response

Defenders are deploying AI for behaviour analytics, anomaly detection, and real-time incident response. Some AI systems now exceed 98% detection rates in high-risk environments.

Continuous Monitoring & Automation

Networks, endpoints, cloud workloads, and AI interactions must be continuously monitored. Automation enables rapid response at machine speed.

Threat Intelligence Platforms

These platforms enhance proactive defence by integrating real-time adversary TTPs into detection engines and response workflows.

Bug Bounty & Vulnerability Disclosure Programs

Crowdsourcing vulnerability detection helps organisations close exposure gaps before adversaries exploit them.

Challenges & Gaps in Current Defences

Many organisations still cannot respond at Gen AI speed.
Defensive postures are often reactive.
Legacy tools are untested against polymorphic or AI-powered threats.
Severe skills shortages in AI/cybersecurity crossover roles.
Data for training defensive models is often biased or incomplete.
Lack of governance around AI model usage and security.

Roadmap: How to Get Ahead

Pilot AI/Automation – Start with small, measurable use cases.
Integrate Threat Intelligence – Especially AI-specific adversary techniques.
Model AI/Gen AI Threats – Include prompt injection, model misuse, identity spoofing.
Continuous Improvement – Track detection, response, and incident metrics.
Governance & Skills – Establish AI policy frameworks and upskill the team.
Resilience Planning – Simulate AI-enabled threats to stress-test defences.

Metrics That Matter

Time to detect (TTD)
Number of AI/Gen AI-involved incidents
Mean time to respond (MTTR)
Alert automation ratio
Dwell time reduction

Conclusion

The cyber-arms race has entered a new era. AI and Gen AI are force multipliers for attackers. But they can also become our most powerful tools—if we invest now. Legacy security models won’t hold the line. Success demands intelligence-driven, AI-enabled, automation-powered defence built on governance and metrics.

The time to adapt isn’t next year. It’s now.

More Information & Help

At MicroSolved, Inc., we help organisations get ahead of emerging threats—especially those involving Gen AI and attacker automation. Our capabilities include:

AI/ML security architecture review and optimisation
Threat intelligence integration
Automated incident response solutions
AI supply chain threat modelling
Gen AI table-top simulations (e.g., deepfake, polymorphic malware)
Security performance metrics and strategy advisory

Contact Us:
🌐 microsolved.com
📧 info@microsolved.com
📞 +1 (614) 423‑8523

References

IBM Cybersecurity Predictions for 2025
Mayer Brown, 2025 Cyber Incident Trends
WEF Global Cybersecurity Outlook 2025
CyberMagazine, Gen AI Tops 2025 Trends
Gartner Cybersecurity Trends 2025
Syracuse University iSchool, AI in Cybersecurity
DeepStrike, Surviving AI Cybersecurity Threats
SentinelOne, Cybersecurity Statistics 2025
Ahi et al., LLM Risks & Roadmaps, arXiv 2506.12088
Lupinacci et al., Agent-based AI Attacks, arXiv 2507.06850
Wikipedia, Prompt Injection

* 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.