Here's a question every CIO, CISO, and CTO should be able to answer right now: if your most privileged AI agent were compromised tonight, how many business domains does the blast radius cover, what regulated data does it touch, and what is the business exposure if you don't act on it?

If you can't answer that — and almost nobody can — then you have a governance gap that no amount of access control will close.

Closing that gap is our mission. As CTO of Relyance AI, I've watched organizations invest heavily in DSPM, identity governance, CIEM and runtime analytics — and still have no answer to the question above. Today we're launching the 24/7 Data Defense Engineer — a continuous monitoring and analysis agent that combines two things never measured together: how much organizational freedom an agent's entitlements actually grant it, and exactly what data sits in its path when it exercises that freedom. We'll be debuting this at RSA and making continuous updates after launch. The goal: a system that maps every finding to its security severity, its business impact, and the organizational exposure of leaving it unresolved — and then suggest concrete remediation measures, so your security team isn't just seeing what's wrong but getting actionable guidance on how to secure what matters most.

The real problem isn't access control. It's organizational exposure.

AI agents are in production. Your IT helpdesk agent provisions accounts and resets credentials across your identity provider. Your finance agent reconciles invoices across ERP, payment gateways, and your general ledger. Your customer support agent pulls order history, accesses account records, and updates CRM fields.

Each has a blast radius — the organizational scope of what goes wrong if it's compromised, misconfigured, or manipulated. In most organizations, that blast radius has never been calculated. It wasn't part of the deployment decision. It isn't on any dashboard.

Security teams have built deep stacks for managing identity risk. All of it was designed for human actors operating at human timescales. None of it was designed to measure the Autonomous Reach of an entity that chains permissions across systems in milliseconds.

Permissions tell you whether an action is allowed. They don't tell you how much of the organization a single identity could influence if something goes wrong. Two agents with identical permission policies can represent completely different risks depending on what those policies are scoped to — one acts within a single system, the other spans finance, HR, and your production customer database.

Threat modeling addresses this in theory, but it's a point-in-time exercise. By the time findings are actioned, the environment has diverged from the model. That's not a failure of process — it's a mismatch between a periodic methodology and a continuously changing attack surface.

Autonomous Reach: the property that permissions don't capture

Posture management tells you what an agent is allowed to do. It doesn't tell you how far that agency extends across your organization when the agent acts autonomously. We built a measure for that gap. We call it Autonomous Reach.

The intuition is straightforward: the risk with agentic AI isn't that an agent has permissions across organizational boundaries. It's that nothing stops it from exercising all of them, continuously, at machine speed.

To understand how we measure it, start with how data moves. A stride is one leg of a data journey. Data enters a business domain through an API call, a pipeline job, or an agent action, travels through the systems and services inside that domain, and exits. That transit is a stride. Each business domain is a composite of the apps, services, data ecosystem (databases, object stores, warehouses, lakes), business processes, and operational activities that define a functional area of your organization. Data Journeys maps every stride end to end, from source code through APIs, data pipelines, SaaS applications, and AI models.

Autonomous Reach scores the organizational distance between the farthest strides that an agent is entitled to act upon: how many business domain boundaries it can cross. It's a property that authorization defines but doesn't measure. Every access control system in production today was designed with an implicit assumption: a human would exercise judgment at each boundary. Autonomous agents removed that assumption. An agent can satisfy every policy you have and still span multiple business units, data domains, and compliance jurisdictions. Perfectly authorized is not the same as safe.

Least privilege doesn't solve this either. Least privilege minimizes permissions per system. But an agent holding minimal access across many systems simultaneously can still accumulate enormous Autonomous Reach, and it's exercising that Reach every second it's running, not once a quarter when a human logs in.

How much of this organization can a single autonomous agent influence, right now, without anyone watching?

What's actually at risk when an agent crosses boundaries

Autonomous Reach tells you the organizational span. But a wide-reaching agent that only touches encrypted, tokenized data is a very different conversation from one that reaches unencrypted SSNs in a production database.

Data Journeys makes Autonomous Reach actionable by classifying what sits at every stride along four dimensions:

Data types. Social Security numbers, credit scores, government-issued identifiers, biometric data, not broad categories like "PII." The granularity matters because your team can't triage on broad labels. Knowing that an agent can reach "PII" is an observation. Knowing it can reach unencrypted Social Security numbers is a priority.

Data state. How data is protected (or not) at a given stride. Most tools look for encrypted, tokenized, or masked. The reality is broader: unencrypted, unmasked, weakly hashed, obfuscated, and many variations in between. The state determines whether a finding is a compliance violation or a posture improvement.

Data location. Both the physical geography where data resides and the specific cloud region it's deployed in. Data residency obligations are defined at both levels. Missing either one turns a finding into an incomplete picture.

Data subject. The category of the individual the data belongs to: customers, employees, patients, minors, applicants, and others. The subject determines which regulatory frameworks apply, but it also tells you something more fundamental. Data subjects are how you identify your organization's crown jewels. Your customer data isn't just a compliance category. It's the asset your business runs on, the data whose breach makes the front page. Understanding data subjects in the context of Autonomous Reach means understanding which agents have a path to your crown jewels, how wide that path is, and what controls stand between an agent and the data that matters most.

We've run this across multiple petabyte-scale customer ecosystems — structured databases and unstructured stores including documents, emails, spreadsheets, and freeform text. At that scale, regex-based classification breaks. Pattern matching generates too many false positives on structured data and misses too much in unstructured content where sensitive information is embedded in natural language or scattered across semi-structured formats.

How we classify: progressive filtering with post-trained small models

We built a multi-stage pipeline powered by post-trained small language models — purpose-built, not general-purpose LLMs repurposed for classification.

Each stage optimizes for high recall, casting a deliberately wide net, then passes results forward for refinement. In data security, a missed finding is far more expensive than a false positive filtered downstream. So we stack multiple high-recall filters in series, each operating on a narrower, richer input set.

Stage 1: Schema-aware pre-classification. For structured data, a lightweight model trained on thousands of real-world schemas scores every field for likely sensitivity using metadata signals — column names, data types, field distributions. For unstructured data, we extract and normalize text, apply language detection, and segment into classifiable units. This stage is intentionally aggressive: it ensures nothing sensitive passes through unexamined.

Stage 2: Domain-specific SLMs. The narrowed candidate set is processed by a family of small language models, each post-trained on domain-specific corpora — healthcare, financial, HR, legal, customer communications. These are purpose-built specialists. Post-training on domain data means they can distinguish a Social Security number referenced in a policy document from one stored as a live data field, or identify a credit score embedded in unstructured customer correspondence that regex would never catch. The post-training process pushes accuracy well beyond zero-shot prompting of larger models, at a fraction of the compute cost.

Stage 3: Contextual adjudication. When earlier stages disagree or a data element could map to multiple data types, an adjudication model weighs the full context: source system, data flow path, co-occurring fields, historical patterns, and organizational policy. This model is also post-trained on adjudication examples from real customer environments with manually verified ground truth.

Each filter maintains recall above 99%. Chained in sequence, the false positive rate drops significantly at each stage while the true positive rate stays near-ceiling. Across production deployments at petabyte scale, this pipeline delivers classification accuracy consistently above 96% on both structured and unstructured data.

Accuracy at petabyte scale means nothing if the cost and latency make it impractical to run continuously. This is where the pipeline's efficiency becomes as important as its accuracy. Between stages, we use entropy-based methods to evaluate the information density of content before committing to compute it. Content with low entropy — repetitive structures, boilerplate, template-generated text, near-duplicate records — carries very little new signal. Rather than processing it through the full model stack, we score its information content and skip past what doesn't warrant deeper analysis. This dramatically reduces the volume of data that reaches the more expensive post-trained models in Stages 2 and 3, keeping both latency and cost low enough to sustain continuous classification across petabyte-scale environments without requiring customers to choose between coverage and budget.

Classification accuracy is the foundation. If your data map is wrong, your Reach calculations are wrong. If your data type labels are unreliable, your findings are noise.

The 24/7 Data Defense Engineer: Autonomous Reach meets Data Journeys

The 24/7 Data Defense Engineer operates continuously, combining Autonomous Reach analysis with Data Journeys classification to surface findings that carry both security severity and business impact.

When it surfaces a finding — an overprivileged identity with destructive permissions scoped to unencrypted customer SSNs in a US production environment — it maps the full picture. Which strides are affected? Which business units does the Reach span? Which compliance frameworks apply based on the data location, data subject, and data type? The output isn't "this agent can write to this table." It's "this agent can modify credit score data across two business units, affecting customer data subjects in the EU, with findings mapped to GDPR Article 25, CCPA, and PCI DSS."

That's the shift from alerting to prioritization — and from prioritization to action. You don't lack findings. You lack the ability to rank them by what matters to the business and then act on them. The 24/7 Data Defense Engineer reasons through the organizational exposure — the strides involved, the data at risk, the compliance surface — and suggests concrete remediation measures. Not generic best practices, but specific guidance informed by how your systems are actually connected and what's actually flowing through them.

Threat modeling gives you a document. The 24/7 Data Defense Engineer gives you a shift report — grounded in how your systems work today, not how they were architected six months ago.

An obvious question: if the 24/7 Data Defense Engineer is itself an agent operating across your environment, what governs it? The answer is that it operates under the same Autonomous Reach constraints it measures — scoped, auditable, and subject to the same policies it enforces.

Why this matters now

A growing share of new code is AI-generated. Every pull request from an AI coding assistant is a potential new stride — a new API call, a new integration, a new agent entitlement — at a pace no human team can audit in real time. The SaaS vendors, third-party integrations, and partners in your data ecosystem are already generating these strides. Their code is already flowing data into your environment.

The threat model from last quarter didn't account for strides that didn't exist when the session ran. The agent entitlements from last month's sprint may have created Autonomous Reach you've never measured.

The question I keep coming back to: can your security posture keep pace with your engineering velocity? If the answer is no — and for most organizations it is — then you need a system that watches continuously, classifies accurately at scale, and translates every finding into the business terms that drive prioritization.

Closing

Your existing identity stack — permissions, IGA, PAM, threat modeling — is necessary. None of it is sufficient for the speed at which agentic systems are creating new organizational exposure.

Autonomous Reach makes agentic blast radius measurable across the strides that define how data moves through your organization. Data Journeys, powered by purpose-built classification at petabyte scale, makes it visible — down to the specific data dimensions. The 24/7 Data Defense Engineer brings them together into a continuous system that surfaces findings with both their security severity and their business impact.

We're launching the 24/7 Data Defense Engineer at RSA, with continuous updates to follow. The premise is simple: every authorization model in production today assumes a human at the boundary. Agents removed that assumption. The tooling hasn't caught up yet, and that's the gap we're building into.

Learn more about the 24/7 Data Defense Engineer. Request a demo today.