Articles | Callibrity IT Consulting | Custom Software Development

/compliant isn't secure: data protection in the age of ai agents

Written by Callibrity | Sep 2, 2026, 5:39:52 PM

Part one of a face-to-face conversation between James Carman and Sid Dutta, President and CEO of Privaclave AI. Being compliant is not the same as being secure, and the Equifax breach is the case study that proves it. Sid walks through why data-centric security has stalled for two decades, what changed the moment AI agents started acting on a human's behalf, and why identity does not equal intent.

Prefer another app? Listen on Spotify, Amazon, Overcast, Pocket Casts, YouTube Music, and more.

At a glance

Guest: Sid Dutta, President and CEO, Privaclave AI

Episode: /compliant isn't secure: data protection in the age of ai agents

Published: June 10, 2026 · 1 hour 23 minutes

Sid Dutta has spent twenty-four years in data protection, including cryptographic services at American Express, global head of data protection at Worldpay, and VP of data protection and privacy engineering at Activision Blizzard through its acquisition by Microsoft Gaming. He founded Privaclave in 2024. His argument in this episode is that the industry has spent two decades protecting the perimeter and the pipe while leaving the data itself in the clear, that every regulation is a floor rather than a ceiling, and that AI agents did not create this problem so much as remove the last excuse for ignoring it. The line he keeps returning to: identity does not equal intent.

Key takeaways

  • Compliance is a floor, not a ceiling. Sid's framing is that regulations describe the minimum an organization can defend in an audit, and that passing an audit and being secure are different claims about different things. An organization can satisfy every control on the list and still be one credential away from a full data loss.
  • Equifax is the clearest illustration, and it was not one failure. It was a chain: an unpatched Apache Struts vulnerability got an attacker in, a flat internal network let them move, and hard-coded credentials sitting in the environment opened access to fifty-one databases. None of those links is exotic. Every one of them is common.
  • Encryption at rest did nothing, because the attacker had valid credentials. This is the part Sid wants people to sit with. The data was encrypted. The system decrypted it on request, exactly as designed, because the request came with credentials the system recognized. Encryption at rest defends against a stolen disk, not against a legitimate-looking query.
  • Seventy-one days of exfiltration, and the monitoring was blind. Data left slowly enough to look like traffic, and the egress inspection that should have caught it was not inspecting, because a certificate had expired. The detection layer was present, funded, and not working.
  • Data-centric security stalled for economic reasons, not technical ones. Retrofitting protection into an existing application took six to nine months of SDLC work per application. At American Express the program ran into the hundreds of millions of dollars. Adoption collapsed the moment the funding stopped, because developers are measured on shipping features, not on protecting fields.
  • Desensitization is the practical middle path, and it has more shapes than people expect. Deterministic tokenization preserves referential integrity so joins still work across systems. Probabilistic encryption varies the output using an initialization vector, nonce, or tweak, which is stronger but breaks searchability, so teams add a hash column to search on. Moving production data into test environments is the use case almost everyone has and almost nobody has solved.
  • "AI didn't create a data security problem, it amplified it." The exposure was already there. What changed is that the systems reaching into it are no longer deterministic. A traditional application queries what it was written to query. An agent responds to a prompt, and one prompt can reach across silos that were never meant to be joined.
  • Identity does not equal intent. An agent inherits a person's permissions the instant it is given their credentials. It does not inherit the reason those permissions were granted. The access control layer sees a valid identity and approves, which is exactly what it was built to do and exactly the wrong answer.
  • James's version of the same point is a note on the fridge. If you leave a note asking someone to pick up milk and cigarettes, and they hand the note to a kid, the store clerk is checking the note's authority, not the kid's. And a note can be reused later, by someone else, long after the errand was over.
  • The shift is from static inventory to runtime enforcement. Knowing what sensitive data you hold is a point-in-time snapshot that is wrong shortly after you take it. Runtime visibility asks what is being accessed right now, by whom, in what context. Enforcement is the layer that can then say no.
  • Intent analysis needs more than the prompt. Sid lists entitlements, roles, historical access patterns, business function, and behavioral baselines alongside the prompt itself. The prompt on its own is not enough signal to distinguish a reasonable request from an unreasonable one.
  • Start out of band, then go inline. Monitoring alongside the traffic tells you what is happening without adding latency or becoming a single point of failure. Inline enforcement is where the actual protection lives, and it is a real performance conversation, so most organizations should earn their way to it rather than start there.
  • Token economics are pushing work toward smaller, local models. Sid expects more specialized small language models and more locally hosted open-source models, because the cost per token on frontier models does not survive contact with high-volume enterprise workloads.
  • Governance should be enablement, not a gate. Sid's position is that models are commoditizing and governance is the durable differentiator. James's addition, borrowing from Jurassic Park, is that if you block people outright, nature finds a way, and what you get is shadow IT rather than compliance.

Host and guest

James Carman

Host, The Forward Slash · Chief Technology Officer, Callibrity

James Carman is the host of The Forward Slash podcast and Chief Technology Officer at Callibrity, where he champions building software that empowers people and drives meaningful outcomes. With a passion for modern architecture and a human-first mindset, he helps organizations scale smartly, without the red tape. An active mentor, speaker, and open-source contributor, James is dedicated to growing leaders and using tech as a force for good.

Sid Dutta

President and CEO, Privaclave AI

Sid Dutta is President and CEO of Privaclave AI, which he founded in 2024 to focus on runtime enforcement rather than static data inventories. He is a certified CISO, a startup security advisor, and holds multiple patents in cryptography, blockchain, and tokenization. Outside of work he played competitive cricket for decades, retiring in 2024, and he leads the South Asian fusion and Bollywood band Jhoom 513. linkedin.com/in/sid-dutta

Frequently asked questions

What is the difference between being compliant and being secure?
Compliance is the minimum set of controls a regulation requires you to demonstrate. Security is whether the data is actually protected against the way attacks really unfold. Sid treats every regulation as a floor, and the episode's argument is that an organization can pass its audits and still lose everything, because the audit checks that a control exists rather than that it works under the conditions an attacker creates.
Why didn't encryption at rest stop the Equifax breach?
Because the attacker was using valid credentials. Encryption at rest protects against someone walking off with the storage. It does not protect against a query that arrives with credentials the system recognizes, because at that point the system decrypts and returns the data exactly as it was designed to. The credentials in that case were hard coded in the environment and opened access to fifty-one databases.
Why hasn't data-centric security been adopted more widely?
Cost and incentives. Retrofitting field-level protection into an existing application ran six to nine months of SDLC work per application, and at American Express the overall program reached the hundreds of millions of dollars. Sid's observation is that adoption dropped off as soon as dedicated funding ended, because development teams are measured on delivering features, and security work that slows a release is work nobody is rewarded for.
What is desensitization, and how is it different from encryption?
Desensitization is the broader category of making data unusable to an attacker while keeping it useful to the business. Deterministic tokenization produces the same output for the same input, which preserves referential integrity so records still join across systems. Probabilistic encryption introduces an initialization vector, nonce, or tweak so the same input produces different output, which is stronger but makes the field unsearchable, so teams commonly add a hash column to search against.
How do AI agents change the data security problem?
Traditional applications are deterministic: they query what they were written to query. An agent is not. It responds to a prompt, and a single prompt can pull from data silos that were never intended to be combined. As Sid puts it, AI did not create a data security problem, it amplified one that was already there.
What does "identity doesn't equal intent" mean in practice?
An agent operating on your behalf carries your permissions but not your reasons. The access control layer checks whether the identity is authorized and approves, which is correct behavior for the layer and the wrong outcome for the organization. The gap is that nothing in the stack is evaluating whether this particular request, from this particular agent, in this particular context, makes sense.
What signals go into evaluating intent?
More than the prompt. Sid names entitlements, role, historical access patterns, business function, and behavioral baselines, evaluated together with the request itself. The prompt in isolation carries too little information to separate a reasonable request from an unreasonable one.
Should enforcement be inline or out of band?
Both, in sequence. Out-of-band monitoring gives you visibility without adding latency to the request path or introducing a new single point of failure, which makes it the sensible starting point. Inline enforcement is where the actual blocking happens, and it is a genuine performance tradeoff, so most organizations should build confidence out of band first.
Is post-quantum cryptography something to act on now?
Yes, but as planning rather than panic. Sid's view is that the threat is real and the timeline is being overstated in both directions. The mechanism worth understanding is that asymmetric cryptography wraps the symmetric keys, so breaking the asymmetric layer later unlocks data captured today, which is the harvest-now-decrypt-later concern. His practical filter is whether your data still has value in five to seven years. NIST has published four algorithms, so the standards exist to plan against.

Ship It or Skip It

The pattern: Is post-quantum cryptography a real, near-term concern, or is it being oversold?

Verdict: ship it, with the panic removed. Sid's answer separates the threat from the urgency around it. The threat is real, and the reason is structural: asymmetric cryptography is what protects the symmetric keys, so an adversary who captures encrypted traffic today can decrypt it whenever the asymmetric layer falls. That is harvest now, decrypt later. What he pushes back on is the framing that everything must be migrated immediately. The triage he suggests is to ask whether a given dataset still has value in five to seven years, and to start with the data where the answer is yes. NIST has published four post-quantum algorithms, so this is planning work against real standards rather than speculation. He has written on this at more length in Cyber Defense Magazine.

"AI didn't create a data security problem, it amplified it."

 

Where to find Sid Dutta

Sid is on LinkedIn at linkedin.com/in/sid-dutta, and Privaclave AI is at privaclave.ai.

 

 

Got a topic for us?

The Forward Slash runs on questions worth arguing about. If there is something you want James to dig into, or someone you think belongs on the show, tell us.

theforwardslash@callibrity.com