Category Archives: Risk Management

Vendor Evidence Is Now a Cyber Materiality Risk

Posted on by
Reply

A cybersecurity incident does not care where your data lives.

It does not care that the affected application is vendor-managed. It does not care that the logs are in a SaaS console your team cannot access. It does not care that the data-flow diagram is maintained by procurement, that customer-impact details live with a managed service provider, or that the outage timeline depends on a third-party support ticket.

But your materiality decision may care very much.

Public companies must disclose material cybersecurity incidents on Form 8-K within four business days after determining that the incident is material. The SEC’s rule also requires disclosure of the material aspects of the incident’s nature, scope, timing, and impact or reasonably likely impact, and the materiality determination must be made without unreasonable delay after discovery.

That creates a practical problem many organizations have not fully internalized:

The disclosure clock may be yours, but the evidence may belong to someone else.

That is not just a legal nuance.

It is an operational design problem.

It is a governance problem.

Continue reading →

AI Agents Need Autonomy Budgets, Not Just Governance Policies

Posted on by
Reply

Most organizations are granting AI agents authority faster than they are defining the limits of that authority.

That is the problem.

We have already started treating AI agents as digital workers. That is the right mental model. An agent that can access data, call tools, trigger workflows, generate artifacts, influence decisions, or alter enterprise state is not just another application. It needs identity. It needs boundaries. It needs oversight. It needs evidence. It needs a human owner. It needs a kill switch. That has been the right foundation for agent governance.

But it is not enough.

There is another question that needs to be asked much earlier:

How much damage is this agent allowed to cause before a human must approve the next action?

Not theoretically.

Not in vague risk language.

In actual economic terms.

How much money can it spend?
How many systems can it change?
How many records can it touch?
How much customer impact can it create?
How much privacy exposure can it cause?
How much reputational risk can it accumulate?

If we cannot answer those questions, we have not governed autonomy.

Continue reading →

Account Recovery Is Becoming the New Identity Attack Surface

Posted on by
Reply

As passkeys and phishing-resistant authentication reduce password risk, attackers will move pressure to the recovery plane.

The industry is moving in the right direction.

Passkeys, FIDO2/WebAuthn, hardware security keys, conditional access, better MFA policies, and risk-based sign-in controls are all meaningful improvements. They reduce entire classes of credential theft. They make phishing harder. They remove reusable passwords from many authentication ceremonies. They shift more of the security burden from user judgment to protocol design.

That is good.

But it is not the finish line.

In my recent passkeys article, I called out a point that deserves its own treatment: passkeys do not solve weak account recovery, help desk social engineering, stolen session tokens, OAuth consent abuse, unmanaged vendor access, or excessive privilege. They are a major step forward, but they do not remove the rest of the identity attack surface.

That matters because attackers adapt.

Continue reading →

Passkeys, Not Passcodes: A Practical Enterprise Guide to Moving Beyond Passwords

Posted on by
Reply

There is a small terminology problem in the identity world right now, and it matters more than it looks.

A passcode or PIN is usually a local unlock secret. It unlocks a phone, a laptop, Windows Hello, an authenticator app, or a hardware security key. A passkey is different. A passkey is the standards-based replacement for passwords, built on FIDO2/WebAuthn. The user unlocks the passkey locally with a fingerprint, face scan, device PIN, pattern, or security key, but the website or application receives cryptographic proof — not a reusable password. FIDO defines passkeys as FIDO authentication credentials based on FIDO standards, tied to an account, and used with the same process the user already uses to unlock a device.

That distinction is not pedantry. It is the difference between a local unlock method and a replacement for one of the most abused controls in the history of computing.

Passwords have had a long run. They also have had a long list of failures: reuse, phishing, spraying, stuffing, database theft, weak reset workflows, help desk abuse, and user fatigue. We have spent decades trying to compensate for those failures with complexity rules, expiration schedules, password managers, SMS codes, mobile push prompts, training campaigns, and detective controls.

Some of those helped. Some just moved the pain around.

Passkeys change the model.

Continue reading →

The Evidence Supply Chain: How CISOs Build a Cyber Materiality Data Plane Before the Incident

Posted on by
Reply

A ransomware incident does not wait for the organization chart to catch up.

At 8:17 a.m., the SOC sees encryption activity on a file server. At 8:31, operations says the plant is still running. At 8:44, finance says revenue recognition may be affected if order processing stays down past noon. At 9:02, legal asks whether customer data was accessed. At 9:18, the forensic team says it is too early to tell. At 9:23, a vendor says the outage may have started in their environment. At 9:41, communications asks whether they should prepare a holding statement.

By hour two, everyone is working hard.

But they are not necessarily working from the same reality.

That is the problem.

Cyber materiality is often discussed as a decision problem. When does a cyber event become a board-level business event? When does it become reportable? When does it become material to investors, customers, regulators, lenders, or strategic partners?

Those are important questions. Public companies, for example, must disclose material cybersecurity incidents on Form 8-K within four business days after determining materiality, including the material aspects of the incident’s nature, scope, timing, and impact or reasonably likely impact.

But underneath that decision sits a deeper problem:

Continue reading →

Cyber Materiality Engineering: How CISOs Pre-Decide When Risk Becomes a Board Event

Posted on by
Reply

A ransomware incident does not stay technical for very long.

For about the first fifteen minutes, it may look like a security operations problem. A strange alert. A locked server. A suspicious authentication chain. A vendor portal behaving badly. A handful of systems no longer responding the way they should.

Then the blast radius starts to widen.

Operations wants to know whether they can keep running. Finance wants to know whether revenue recognition, cash movement, reserves, or forecasts are exposed. Legal wants to know whether notification clocks have started. The CEO wants to know what can be said, to whom, and when. The board wants to know whether this is “material.” Investors may eventually ask the same thing, only with less patience and more lawyers.

This is where many organizations discover that their cyber incident response plan is not really an enterprise decision plan. It tells people who to call. It tells the SOC how to preserve evidence. It may even have a communications tree and a sample press statement.

But it often does not answer the question that matters most in the first few hours:

Continue reading →

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

Posted on by
Reply

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.

AIAgentBanner

Continue reading →

Why My AI Agents Needed CaneCorso as a Security Control Plane

Posted on by
Reply

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

Continue reading →

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

Posted on by
Reply

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.

Continue reading →

Introducing CaneCorso: An AI Application Firewall Built for Real Workflows

Posted on by
Reply

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.

Continue reading →