Traversal Raised $120 Million to Build a Superintelligent AI Site Reliability Engineer. Its Monthly Investigation Volume Grew 142x in 2026.
Sentra raised $150M led by Capital One Ventures as enterprises discovered AI agents inherit every permission their service accounts hold — including access to sensitive data nobody intended them to have. At 300%+ growth and $260M in total funding, Sentra is building the data access governance layer that agentic AI requires.
Sentra raised $150 million in a strategic investment round announced November 4, 2026, led by Capital One Ventures. Bessemer Venture Partners, Zeev Ventures, Standard Investments, Munich Re Ventures, and Key1 Capital also participated, bringing Sentra's total funding to over $260 million. The company says its business grew more than 300% over the past year.
The timing is not coincidental. Capital One is both the round's lead investor and a Sentra customer — a financial institution that is deploying AI agents at scale across customer service, fraud detection, and credit operations, and that has a firsthand view of what happens when those agents inherit service account permissions that were never designed for AI access. The round is Capital One saying, in investment form, that agentic data security is not an optional layer.
This piece examines what Sentra is addressing, why the access inheritance problem is more pervasive than most enterprises realize, what the technical approach differs from traditional DLP, and what enterprise security teams need to do before their AI agent deployments create the data exposure they are funding to prevent.
The Access Inheritance Problem
When an enterprise deploys an AI agent — a copilot, a sales assistant, an automated workflow — the agent runs under an identity. Usually that identity is a service account: a non-human account provisioned to allow applications to authenticate against APIs, databases, and cloud services.
Service accounts in most enterprises are not clean. They are provisioned incrementally over years, accumulating permissions as systems evolve, teams change, and applications are retired or repurposed. A service account that was originally created for a reporting application in 2019 may have been given access to HR data in 2021 to support a new analytics workflow, then given access to CRM data in 2023 for a sales reporting integration. By 2026, that same service account — running as the identity for a newly deployed AI copilot — has access to HR records, financial data, customer PII, and CRM data that the AI agent was never intended to touch.
This is not a hypothetical scenario. It is the default state of enterprise service account inventories. The Menlo Ventures 2026 State of Enterprise AI report found that enterprises have deployed AI agents at a faster pace than they have updated their access governance — a gap that Sentra's 300% growth directly reflects.
The access inheritance problem is different from traditional insider threat. A human employee with overly broad permissions is constrained by human behavior: they can only act as fast as a human can act, they leave behavioral traces that deviate from expected patterns, and they face legal accountability for misuse. An AI agent with overly broad permissions can act at machine speed, can be prompt-injected to exfiltrate data it normally wouldn't touch, and may operate in ways that look entirely normal to access logs because every query is technically authorized.
Why Capital One Led This Round
Capital One's decision to lead a $150M round in an enterprise security vendor is worth examining beyond the headline.
Capital One is a data company that runs as a bank. It manages cardholder data for tens of millions of customers, makes credit decisions using machine learning models, operates customer service workflows through AI assistants, and uses AI agents for fraud detection in real time. Each of those functions represents a surface where AI agents with over-permissioned service accounts create material regulatory risk — specifically under PCI DSS for cardholder data, under FCRA for credit data, and under GLBA for customer financial information.
Capital One has also been the target of one of the most significant data breaches in U.S. financial services history — the 2019 incident that exposed 100 million customer records and resulted in substantial regulatory fines. The institutional memory of that event shapes Capital One's approach to data access governance. A bank that paid the consequences of an access misconfiguration does not need to be persuaded that access governance for AI agents is worth investing in.
The strategic investor dynamic compounds the signal. When a large enterprise leads a vendor round for a tool it is using internally, the message is that the tool's performance in production — in the most demanding environment possible — justified the investment. Capital One's vendor selections in security are watched by other financial services institutions. Its decision to lead Sentra's round will be read by JPMorgan, Wells Fargo, and others as a category signal from a peer institution that has done the diligence.
Sentra's Technical Approach: Posture Before Detection
The prevailing model in enterprise data security is perimeter detection: monitor what data is moving, where it is going, and block transfers that violate policy. This approach made sense when data movement meant human employees downloading files or emailing attachments. It is insufficient for AI agents, which access data through API calls that look identical to legitimate application traffic.
Sentra's approach operates at the access posture layer rather than the data flow layer. Instead of monitoring what data is moving, Sentra maps what data is accessible — by whom, through what accounts, and with what level of sensitivity — and enforces minimum-privilege access as the baseline state.
The practical mechanics work in four steps:
1. Discovery. Sentra scans the enterprise data environment — cloud storage (S3, Azure Blob, GCS), SaaS platforms (Salesforce, ServiceNow, Workday, SharePoint), data warehouses (Snowflake, Databricks, BigQuery), and file shares — and classifies every data asset by sensitivity level: PII, PHI, cardholder data, financial records, intellectual property.
2. Access mapping. Sentra maps every identity that can reach each data asset: human users, service accounts, and AI agents. Critically, it maps inherited access — a service account with broad permissions grants the same access to any AI agent that runs under it, even if the agent was provisioned for a narrow function.
3. Gap analysis. Sentra identifies the gap between what each identity needs to do its job and what it can actually access. For AI agents, this gap is typically large: a support agent that needs to read the customer's ticket history and product documentation may technically have access to billing records, HR data, and internal financial reports through its inherited service account permissions.
4. Remediation and enforcement. Sentra recommends permission reductions that bring each identity to minimum necessary access and can enforce those reductions continuously — if an agent's access scope expands outside approved bounds, Sentra alerts and can automatically revoke the unauthorized permissions.
The critical differentiator in this approach is that Sentra runs entirely within the customer's environment. The analysis of what data exists and who can reach it never leaves the customer's cloud. This matters for regulated industries: a bank or healthcare provider cannot route patient or cardholder data through a third-party security tool's infrastructure, but they can run Sentra's analysis engine within their own perimeter.
| Approach | Traditional DLP | Sentra |
|---|---|---|
| Operating model | Request inspection | Access posture |
| When it acts | As data moves | Before data is accessed |
| AI agent coverage | Partial (behavior-based) | Full (identity-based) |
| Data routing | Through vendor infrastructure | Stays in customer environment |
| Coverage scope | Data in motion | All data, at rest and in motion |
| Minimum privilege | Manual policy | Automated enforcement |
The Shadow AI Problem
Sentra's platform addresses what the company calls "shadow AI" — AI agents, copilots, and models that have been connected to enterprise data systems without formal security review.
Shadow AI is the AI equivalent of shadow IT: a business unit deploys a productivity tool (a Salesforce copilot, a Slack-integrated AI assistant, a Notion AI workflow) using an existing service account, without routing the deployment through the IT and security approval process. The business unit is trying to move fast; the security team doesn't know the agent exists.
Shadow IT was a major enterprise risk category in the 2010s, eventually addressed through cloud access security brokers (CASBs) and identity governance tools. Shadow AI creates the same risk at higher speed with higher stakes — AI agents can process and transmit data faster than human employees, and the prompt injection vulnerability creates a pathway for external actors to exploit over-permissioned agents.
The 300% business growth Sentra reported is not just organic demand from enterprises that have already inventoried their AI agent footprint. It reflects the growing awareness that the footprint is larger than IT teams know. When Sentra runs its first access audit for a customer, the common finding is that the number of AI agents, copilots, and models connected to production data systems is two to four times larger than the number IT formally approved. The gap is not malice — it is the result of AI tools being embedded in business applications in ways that do not require IT provisioning.
What 300% Growth Signals About Enterprise Urgency
Sentra's 300% year-over-year growth happened before most enterprises have experienced a material agentic AI data breach. That is unusual.
Enterprise security spending typically follows breaches: a category grows when customers have been hit and need to prevent recurrence. Categories that grow before the breach wave tend to be driven by regulatory anticipation, insurance requirements, or early-mover advantage in enterprises with sophisticated security programs.
All three factors are present for agentic data security. The EU AI Act's Annex III high-risk provisions took effect in August 2026, requiring detailed audit trails for AI systems making consequential decisions. PCI DSS v4.0 enforcement began in 2025, sharpening access governance requirements for cardholder data. Cyber insurance underwriters have begun asking about AI agent access controls in their policy renewal questionnaires — a signal that the insurance market has priced the risk.
The sophistication factor matters too. Capital One, Bessemer's portfolio companies, and Munich Re's insurance customers are not early-stage enterprises experimenting with AI. They are large organizations that have deployed AI at scale and whose security programs are mature enough to identify the access inheritance problem before experiencing a breach from it.
The implication for the broader market: 300% growth in a pre-breach market means the most sophisticated enterprises have identified agentic data security as a priority. The wave of less-sophisticated organizations that move on this after a publicized breach is likely 12-24 months behind. By then, Sentra and the competitors it will attract will have refined their approaches against the most demanding possible environments.
The Competitive Landscape
Sentra is not operating in a vacuum. The agentic data security category is attracting competition from several directions.
Traditional DSPM (data security posture management) vendors — Varonis, Securiti, BigID — have all added AI-specific features to their platforms in 2025 and 2026. The incumbent play is the same as in every adjacent enterprise security category: add AI governance as a module to existing data security platforms, leveraging existing enterprise relationships and integrations.
Cloud security platforms — Wiz, Lacework, Prisma Cloud — have added data security posture capabilities alongside cloud infrastructure security, moving toward the same unified access governance layer from a cloud security angle.
The startup cohort addresses the category more specifically: Sentra (from a data access posture angle), Securiti (from a data privacy and AI governance angle), and several smaller companies addressing specific aspects of AI access governance.
Microsoft's Execution Containers for Windows address a different layer of the same problem — OS-level sandboxing for AI agent execution — and represent the platform-level answer from infrastructure vendors. The difference is scope: Execution Containers limit what an agent can do on a specific machine; Sentra governs what data the agent can reach across the full enterprise data environment.
Sentra's specific advantage is depth in the data access layer: the platform understands data at the classification level, maps inheritance chains through service account hierarchies, and enforces minimum-privilege across heterogeneous environments. That depth, combined with the Capital One deployment, represents a defensible position against incumbents who are adding AI governance features to broader platforms.
The Deployment Playbook for Enterprise Security Teams
For CISOs and enterprise security architects evaluating agentic data security, the deployment logic follows a risk-prioritization framework:
1. Inventory your AI agent footprint first. Before deploying any tool, understand what AI agents, copilots, and models are connected to your production data systems. Use Sentra or a manual audit to identify every AI identity — including agents deployed by business units without formal IT review. The number will likely surprise your security team.
2. Classify data exposure by agent. For each AI agent in your inventory, map what data it can access — not what it is supposed to access, but what its service account permissions allow. Priority score by sensitivity: agents that can reach PII, PHI, cardholder data, or regulated financial records should be audited and remediated first.
3. Enforce minimum privilege for high-risk agents immediately. This step does not require Sentra or any specific tool — it requires the same identity governance practices that apply to human users. Remove permissions that the agent doesn't need for its defined function. For agents running under legacy service accounts with accumulated permissions, create new, purpose-specific service accounts with minimum necessary access and re-credential the agents to those accounts.
4. Add behavioral monitoring for prompt injection detection. The access posture layer addresses inherited over-permissions; the behavioral layer addresses active exploitation. Sentra's behavioral monitoring flags agents that access data outside their normal pattern — but any identity threat detection tool that covers non-human identities can serve this function. The behavior to monitor: access to data classifications the agent normally doesn't touch, unusually high data volumes, access at unexpected times, and query patterns that differ from the agent's established behavior baseline.
5. Build AI identity governance into your security review process. Agents deployed by business units without security review are the most common source of shadow AI. The fix is process, not just technology: require security review for any AI tool that will run under a service account with access to sensitive data. This catches shadow AI at the provisioning stage rather than after deployment.
The Broader Signal for Enterprise AI Governance
Sentra's $150M round, following the Menlo Ventures finding that enterprises spent $177 billion on AI in 2026 while incumbents held 91% of IT spend, points to an emerging pattern in enterprise AI: the security and governance infrastructure required to deploy AI safely is becoming as expensive to build as the AI itself.
This is not surprising in retrospect. Every major enterprise technology transition has generated security infrastructure spending commensurate with the core technology spending. Cloud computing generated cloud security spending. Mobile enterprise generated mobile device management spending. AI is generating AI security spending, and the agentic layer — where AI agents have persistent identities and broad permissions — is generating agentic-specific security spending.
The White House AI Accord's voluntary safety commitments from OpenAI, Anthropic, Google, and Microsoft do not specifically address agentic data security at the enterprise deployment layer. The commitments cover model safety and responsible deployment at the lab level. What enterprises do with those models after deployment — including the access permissions they provision for AI agents — is an enterprise governance problem that labs cannot solve. Capital One, Munich Re, and Bessemer are funding the solution.
Takeaway: Sentra's $150M raise is the clearest signal yet that agentic data security has moved from a theoretical concern to a priority in enterprise AI governance. The access inheritance problem — AI agents running under service accounts with permissions far broader than the agent's intended function — is structural, not incidental. Enterprises that audit their AI agent access footprint today will find that most of their deployed agents have access to sensitive data they don't need. The remediation is not complex; it is the same minimum-privilege principle that has governed human identity management for decades, applied to non-human AI identities. The enterprises that apply it before experiencing a breach will pay with time and tooling. The ones that wait will pay with the breach.
Frequently Asked Questions
What is agentic data security and what problem does Sentra solve?
Agentic data security is the practice of controlling what AI agents can access and do with enterprise data, as distinct from traditional data security which focuses on what human users can access. The problem Sentra solves is a consequence of how AI agents are deployed: they run under service accounts that often have inherited permissions far broader than the specific tasks the agent needs to perform. An AI agent configured to read customer support tickets may run under a service account that has read access to HR records, financial files, and product databases — permissions accumulated over years of human use that nobody audited when the service account was repurposed for the AI agent. Sentra maps the full access footprint of every AI agent, copilot, and model in a customer's environment — including inherited permissions through service account hierarchies — and enforces minimum access principles by identifying and revoking permissions the agent doesn't need. The platform also provides continuous monitoring for agents accessing data outside their normal behavior pattern, which is an early signal for prompt injection attacks, hallucination-driven data exfiltration, or misuse by a compromised agent.
Why did Capital One Ventures lead Sentra's $150 million round?
Capital One Ventures' decision to lead Sentra's $150M round is strategic on multiple levels. Capital One is a financial services company deploying AI agents at scale across customer service, fraud detection, credit underwriting, and operational workflows — exactly the environment where agentic data security failures are most consequential. A data exfiltration incident caused by an AI agent accessing cardholder data it had inherited access to but didn't need represents regulatory, financial, and reputational risk that Capital One is highly motivated to prevent. By leading Sentra's round, Capital One is both investing in a tool that addresses a real internal problem and signaling to peers in financial services that the agentic data security category is mature enough for serious enterprise deployment. The strategic investor dynamic — where a large enterprise leads a vendor round for a tool it uses — is one of the strongest validation signals in enterprise software. Capital One's participation says the technology works in the most demanding possible deployment context: a regulated financial institution with strict data governance requirements and aggressive AI adoption.
How does Sentra differ from traditional data loss prevention (DLP) tools?
Traditional DLP tools work by inspecting data as it moves — monitoring file transfers, email attachments, clipboard operations, and network traffic to identify when sensitive data is about to leave the controlled environment. DLP is a request-inspection model: it evaluates each data transfer as it happens and blocks or alerts on transfers that violate policy. Sentra's approach is different in two respects. First, it works on access posture rather than data flow: instead of inspecting each data request, it maps the full access footprint of every human, service account, and AI agent and enforces minimum-privilege access as the baseline state. Data that an agent should never reach is simply not reachable, rather than being watched and blocked when the agent tries to access it. Second, Sentra runs entirely inside the customer's environment rather than inspecting data at the network perimeter — the analysis of what data exists, who can reach it, and what that access footprint looks like runs in the customer's cloud rather than routing data through Sentra's infrastructure. This matters for regulated industries where data cannot leave the controlled environment even for security analysis.
What enterprise data sources does Sentra protect?
Sentra maps and governs data across the full enterprise data environment: cloud storage (AWS S3, Azure Blob, Google Cloud Storage), SaaS applications (Salesforce, ServiceNow, Workday, SharePoint), data warehouses (Snowflake, Databricks, BigQuery), and traditional file shares. The platform classifies data by sensitivity — PII, PCI, HIPAA-regulated data, intellectual property, financial records — and maps which identities (human users, service accounts, and AI agents) have access to each classification. For AI-specific coverage, Sentra tracks which models, copilots, and agents are connected to which data sources, what data they have been trained on or have access to at inference time, and whether their access patterns match expected behavior. When an agent exhibits anomalous access — reading files outside its normal scope, downloading large volumes of data, or accessing sensitive classifications it has never touched in normal operation — Sentra flags the behavior for investigation. The platform also covers what it calls 'shadow AI' access: service accounts that were originally provisioned for human workflows but have been repurposed to run AI agents without formal security review.
What compliance regulations require agentic data security controls?
No regulation specifically mandates agentic data security controls yet, but several existing frameworks create de facto requirements when AI agents are deployed in regulated environments. GDPR's data minimization principle requires that personal data be accessible only to parties that need it for the specific purpose it was collected for — an AI agent with broad access to customer PII violates data minimization even if no breach occurs. HIPAA's minimum necessary standard requires that covered entities limit the health information accessible to AI systems to what is reasonably necessary for the authorized function. PCI DSS requirements for controlling access to cardholder data apply to AI agents that run under service accounts with cardholder data access. The EU AI Act, whose Annex III high-risk provisions took effect in August 2026, requires detailed audit trails for AI systems making or assisting in consequential decisions — Sentra's access logging directly supports this documentation requirement. The practical enforcement risk is that a data breach involving AI agents will be investigated under existing breach notification and data protection regulations, which will examine what access controls were in place for the agents involved. 'The service account inherited broad permissions and we didn't audit them before attaching the agent' is not a defensible posture under GDPR, HIPAA, or PCI DSS.
How should enterprises prioritize agentic data security in their AI governance programs?
Enterprise AI governance programs in 2026 typically address model selection, output quality, hallucination risk, and access to AI tools. Agentic data security addresses a different layer: the data that agents can touch, not just the outputs they produce. The prioritization logic is a function of two variables: how many AI agents are deployed in production, and what sensitivity level of data those agents can access through their service accounts. An enterprise with 10 AI pilots that touch anonymized data has a different risk profile than an enterprise with 200 production agents running under service accounts provisioned years ago with broad permissions. The assessment should start by inventorying AI agents currently in production, then mapping what data each agent can access — not what it is supposed to access, but what it can access through its service account permissions. In most enterprises that run this audit for the first time, the gap between intended access and actual access is large enough to be a material security risk. The remediation priority should follow data sensitivity: start with agents that can reach PII, PHI, cardholder data, or IP, and enforce minimum-privilege access for those first.