In-environment data scanning is becoming the default control question

At a glance

What this is: This is an analysis of two data security architectures and the finding that in-environment scanning materially changes performance, cost, and regulatory defensibility.

Why it matters: It matters to IAM practitioners because access controls, data governance, and AI oversight increasingly fail when sensitive content is copied out of its original trust boundary for analysis.

By the numbers:

• At petabyte scale, in-environment scanning has processed 9 petabytes in under 72 hours at roughly $40,000 a year.
• In-environment classification is reported at better than 98% accuracy at scale.

👉 Read Sentra's analysis of in-environment scanning versus data egress

Context

Data security architecture is no longer a back-end implementation detail. The key governance question is whether sensitive content stays inside the customer environment during classification or gets copied into a vendor cloud first, because that choice affects control scope, audit posture, and how quickly findings can be acted on.

That distinction becomes sharper in AI-enabled environments where agentic workflows run continuously and data can be recombined through RAG and embeddings. For IAM and data security teams, the issue is not just where results land, but whether the original trust boundary remains intact while analysis happens.

The article is grounded in the practical reality that architecture decisions made early tend to become governance constraints later. That starting position is now typical for teams dealing with regulated data, AI access patterns, and higher audit expectations.

Key questions

Q: What breaks when data classification moves sensitive content into a vendor cloud first?

A: The main failure is trust expansion. Once raw content leaves the customer environment, the organisation takes on a second processing boundary, additional retention questions, and a more difficult audit story. That is especially risky for regulated data, because compliance now depends on how the vendor handles copied content, not just on the customer’s own controls.

Q: Why do RAG systems complicate data access control?

A: RAG can retrieve authorised fragments from multiple sources and recombine them into outputs that were never reviewed as a whole. That means storage permissions alone do not determine what the system can disclose. Security teams need to govern retrieval paths, source entitlements, and output controls together.

Q: How do security teams know if AI governance is working?

A: Look for evidence that access decisions are reviewable, permissions are revocable, and exceptions are not becoming permanent. If the team cannot explain who owns an AI workflow, what it can reach, and when its access was last reviewed, governance is incomplete. Control maturity shows up in traceability, not adoption volume.

Q: Who is accountable when AI tools expose sensitive information or weaken audit evidence?

A: Accountability should sit with the control owner for the workflow, not with the tool itself. Security, IAM, and GRC leaders should define ownership for data-handling rules, approval paths, evidence capture, and exception handling before AI use expands, so responsibility is clear when something goes wrong.

Technical breakdown

In-environment scanning versus data egress

In-environment scanning keeps discovery and classification inside the customer’s own cloud account, with only metadata leaving the environment. Data-egress architectures copy content into the vendor’s cloud for analysis, which introduces latency, duplicate data handling, and a wider trust boundary. The technical difference matters because sensitive content that never leaves its original control plane is easier to govern, revoke, and audit. Once the content is exported, the security model shifts from containment to trust in another processing environment.

Practical implication: validate where content is processed, not just where results are stored.

Why RAG and embeddings change the access-control model

Traditional access controls assume a person opens a discrete document and reads it as a whole. RAG pipelines and embeddings break that assumption by retrieving fragments from multiple sources and recombining them into outputs that may exceed the intent of the original permission model. Compliant storage therefore does not guarantee compliant outputs. The governance problem is not only data-at-rest protection, but how AI systems can synthesise authorised fragments into unauthorised disclosures.

Practical implication: map AI retrieval paths to the permissions that govern source data, not just the storage location.

Continuous agent activity versus periodic review cycles

Agentic AI introduces a timing problem. Governance models built around quarterly review, scheduled scans, or slow remediation loops cannot keep up with systems that operate continuously and generate risk in hours. That mismatch creates operational blind spots even when the underlying controls appear sound on paper. The control failure is temporal as much as technical: the analysis cycle is too slow for the execution cycle.

Practical implication: move from periodic review to continuous monitoring for AI-driven data access patterns.

Threat narrative

Attacker objective: The objective is to obtain sensitive content or derived disclosures outside the customer’s direct control while preserving a plausible processing trail.

1. Entry occurs when regulated data is copied out of the customer environment into a vendor cloud for classification or processing.
2. Escalation follows when embeddings, RAG, or derived outputs recombine content in ways that exceed the intent of the original access controls.
3. Impact is unauthorised exposure, audit difficulty, and slower containment when the copied data or derived outputs need to be explained or revoked.

NHI Mgmt Group analysis

Architecture is now a governance decision, not a deployment preference. In sensitive data programmes, the location of analysis determines the control boundary. If content leaves the customer environment, the organisation inherits a second trust domain, a second retention problem, and a second audit story. That complicates both IAM oversight and data governance because the analysis path becomes part of the risk surface, not just the tool stack. Practitioners should treat processing location as a control requirement.

AI data governance now needs to account for recomposition risk. Storage compliance was never enough, but AI makes the gap visible. RAG and embeddings can surface fragments in combinations that the originating document controls never anticipated, which means document-level permissioning is no longer the full answer. This is where NHI and agentic AI governance intersect with data security: machine-driven access can create outcomes no human review cycle was designed to inspect. Practitioners should govern outputs as well as access.

Continuous analysis is the new baseline, and periodic review is a lagging control. The article’s core point is that slow governance models cannot pace AI systems that operate continuously. That is a timing failure, not just a tooling gap. In NHI and agentic AI programmes, the more relevant named concept is governance lag: the gap between continuous machine activity and batch-based oversight. Practitioners should shorten that gap or accept missed exposure windows.

In-environment scanning better aligns with least-privilege thinking for data. The principle is familiar from IAM: keep access as narrow as possible and avoid unnecessary movement of sensitive assets. When classification happens in place, the platform does not need a broad data copy to do its job, which reduces blast radius and simplifies defensibility. This does not eliminate risk, but it prevents the analysis layer from becoming an additional data repository. Practitioners should prefer architectures that minimise data duplication.

What this signals

Governance lag is the practical risk signal here: continuous AI activity will keep outpacing batch-based oversight unless teams redesign the control plane. That means data security, IAM, and AI governance owners need a common view of where content is processed, how outputs are formed, and which alerts prove the control is actually working.

The wider implication is that architecture choices are now part of identity governance. When analysis happens outside the customer boundary, machine access and data access become harder to separate, so teams should align NHI controls, retrieval policies, and audit evidence around the same trust model.

The article’s timing lesson is clear: the faster systems operate, the less value there is in controls that assume a weekly or quarterly cadence. Continuous verification, tighter data locality, and faster exception handling will matter more than another layer of reporting.

For practitioners

• Classify processing location as a control requirement Require vendors to state exactly where raw content is processed during discovery and classification, and reject proposals that only describe where results are stored. The decision should be recorded in architecture review and vendor risk files.
• Test AI output paths against source permissions Review RAG and embedding workflows to confirm that output generation cannot recombine fragments into disclosures outside intended access scope. Align the review to source permissions, not to storage-only controls.
• Replace batch review with continuous monitoring for agent activity Set alerting and investigation thresholds for continuous AI-driven data access, especially where agents can make retrieval decisions without human approval. Batch scans should be treated as supplemental, not primary, oversight.
• Quantify audit and retention overhead before selection Compare the cost of data movement, deletion attestation, and regulatory explanation work alongside licence fees. A lower sticker price can still produce materially higher operational and compliance overhead.
• Prefer in-environment models for regulated data sets Where law, contract, or sensitivity makes content movement hard to justify, prioritise architectures that keep data inside the customer cloud account during analysis. Use that requirement as a procurement filter before feature comparison.

Key takeaways

• Data security architecture now determines whether classification stays inside the control boundary or creates a second trust domain.
• AI systems can recombine authorised fragments into risky outputs, which means storage compliance is not the same as output compliance.
• Teams should treat processing location, retrieval paths, and monitoring cadence as core governance controls, not implementation details.

Key terms

• Data-egress architecture: A data security model in which content is copied out of the customer environment and processed in the vendor’s cloud. The main governance trade-off is that analysis becomes dependent on another trust boundary, which can increase audit complexity, retention obligations, and exposure scope.
• In-environment scanning: A classification model where discovery and analysis happen inside the customer’s own cloud account or environment. Only metadata or results leave the boundary, which reduces unnecessary data movement and makes the processing chain easier to govern, review, and explain to auditors.
• Governance Latency: Governance latency is the delay between a change in risk, relationship, or access need and the point at which the control model reflects that change. In API environments, high governance latency turns simple access management into a bottleneck and increases residual exposure.
• Recomposition risk: The possibility that an AI system will combine individually authorised fragments into a new output that exceeds the intent of the original access rules. It is a control problem because permissioning for source data does not automatically govern what a model can synthesise.

What's in the full article

Sentra's full article covers the operational detail this post intentionally leaves for the source:

• Side-by-side architecture comparison of in-environment and data-egress scanning models
• Petabyte-scale performance and cost observations from real deployments
• Why compliance, retention, and audit handling differ when data leaves the customer cloud account
• How AI readiness changes the governance case for continuous, in-place analysis

👉 Sentra's full article covers the architecture comparison, cost implications, and AI governance context in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity controls to the broader governance decisions that shape AI and data security programmes.