Drata 行政總裁兼聯合創辦人 Adam Markowitz 訪問系列

Adam Markowitz is CEO and co-founder of Drata, where he is expanding the company’s work in continuous compliance and trust into AI agent governance. Before co-founding Drata in 2020, he founded Portfolium alongside Troy Markowitz and Daniel Marashlian. His experience navigating security questionnaires, audits, and compliance reviews helped shape Drata’s approach to automating how organizations demonstrate trust.

Drata provides a platform for governance, risk, and compliance, combining automated evidence collection, continuous control monitoring, third-party risk management, and security questionnaire workflows. Its AI agent governance capabilities focus on discovering agents, enforcing policies before actions execute, and recording decisions for auditability. In this interview, Markowitz discusses insider agent threats, machine identity, tool-call security boundaries, and the controls enterprises need to deploy autonomous agents at scale.

You previously founded Portfolium before co-founding Drata in 2020, after experiencing firsthand how cumbersome security compliance could become as a company scaled. What led you to believe this was a problem worth building an entirely new company around, and how has Drata’s mission evolved as AI has changed the security landscape?

While leading Portfolium with my cofounders Troy Markowitz and Daniel Marashlian, we learned a valuable lesson: Earning trust in business is a process, not a pitch. Given the high volume and sensitivity of student information, universities and enterprises wouldn’t partner with us until we proved we were doing what we should to protect their data. We realized the slow, painful task of grinding through every security questionnaire, audit and compliance review manually was a shared experience. After Portfolium was acquired, Troy, Daniel, and I reunited and we spent six months building the first version of Drata, talking to dozens of companies and auditors to validate the problem before we even started writing code. When we launched, we hit 100 customers in the first six weeks and 1,000 within the year – which told us that we’d gone from selling something that was a “nice to have” to something people couldn’t operate without.

With AI, Drata’s mission of delivering continuous trust hasn’t changed, but the scope of that trust has expanded. We started by automating the grind of compliance, then pushed into agentic workflows that could run third-party risk assessments and security questionnaires end-to-end. But the real shift came when the agents themselves became the thing that needed governing. Now, we’ve extended the platform to power AI agent governance: discover the agents, govern what they’re allowed to do, and produce evidence that holds up when someone asks.

You’ve introduced the term “Insider Agent Threat” to describe risks created not by an external attacker, but by an organization’s own AI agents. What distinguishes an insider agent threat from the traditional insider threat security teams have spent decades preparing for?

Traditional insider threats are about a person misusing access they already have, such as a disgruntled employee, a careless one, or someone who simply clicks the wrong thing. Security teams have spent decades building programs around that risk, focusing on background checks, least privilege, offboarding checklists, and the like.

The insider agent threat is different because the agent was never granted access in the first place. The risk moves from misuse to acquisition. If an agent is given a goal and the clear path to finish that goal is blocked, it doesn’t just file a ticket and wait like a person would. It tries to find another route, a service account with a weak password, or an endpoint nobody remembered to close. It lets itself in with no malice or policy violation it’s aware of. It does exactly what you asked, and that’s what makes it so hard to catch. Every step looks reasonable in isolation and the agent reports success at the end.

We already know how to govern employees and third-parties with access to sensitive systems, but agents are a third population, and the tools built for the first two don’t reach them.

AI agents can pursue objectives persistently, operate at machine speed, and interact with multiple systems without the judgment a human employee might apply. How fundamentally does this change the enterprise threat model?

It changes the timeline more than anything else. A human probing for a way into a system eventually gets bored, or gets caught, or gives up. An agent doesn’t. An open door that was previously undiscovered gets found now because the agent doesn’t get tired and it doesn’t stop searching.

And it’s not just one door. An agent built to do one task will happily touch a dozen systems on the way to finishing it – pulling account history here, checking a database there – and most of that has nothing to do with what it was actually asked to do. On the way to building one deck, it can pass through another customer’s data, financial records, employee information, whatever’s in its path. None of that shows up as an incident.

So the threat model has shifted. The question a security team should be asking today is how far its own agents will go to finish a task if nobody has told them where to stop.

Many organizations already have identity and access management, privileged access management, and zero-trust architectures in place. Why aren’t those controls sufficient on their own for governing autonomous AI agents?

Those frameworks were built for humans and for vendors — both populations with judgment, both populations that stop when they hit a wall. Agent identity needs the same rigor that was built for humans and third-party risk: discovery, ownership, and proof an auditor can stand behind. The gap is that there is no shared bar yet for what ‘governed’ actually means when the thing holding the credential is an agent.

An agent created by one of your engineers, for example, can act with that engineer’s access – even on systems that engineer never personally touches. IAM and PAM assume the thing holding the credential knows when to stop, but agents don’t come with that assumption built in.

Should enterprises begin treating every AI agent as its own machine identity, with a clearly defined owner, permissions, scope, and lifecycle? What would a mature identity framework for agents look like?

Yes, but most enterprises aren’t there yet. More than you’d expect can’t even tell you how many agents are running inside their walls, let alone who owns each one. A mature framework starts with discovery – a real, continuous inventory of every agent. From there, every agent needs an owner, a defined scope of what it’s allowed to touch, and policy that actually enforces against that scope. From our own research, we see the same failure mode on the vendor side — three in four organizations only re-assess their third parties once a year or less, so they’re governing on data that’s already stale by the time anything changes. Point-in-time doesn’t hold for agents, internal or external

We want one standard that every agent is held to in the same way, instead of security chasing down what each individual developer built on their own. That means policy you can write in plain language, tested against real historical traffic before it’s ever turned on, and then enforced inline so that the framework is running in the path of every action the agent takes and doesn’t just sit in documentation.

One particularly difficult scenario is an agent that violates security policy without behaving maliciously. If an agent discovers an unintended path to sensitive data simply because it is trying to complete its assigned task, how can security teams distinguish successful automation from a security incident?

Right now, the honest answer is that you can’t. Picture a support agent built to draft quarterly business reviews, and it’s told to pull account history and build the deck. The clean path — the export it’s supposed to pull from — comes back empty. A human would stop there, but the agent finds another route and from its perspective, had a successful outcome.

While the task did get done, it got there by going around your security protocols and into systems it wasn’t meant to open. The distinguishing question has to be whether the agent stayed inside the scope we gave it. Finishing the job was never the question. That’s a policy question. It means defining scope tightly enough that ‘successful automation’ and ‘security incident’ don’t look identical after the fact.

Traditional security monitoring often identifies suspicious activity after it occurs, but an autonomous agent may complete hundreds of actions before a human can respond. Does agentic AI require security controls that operate directly in the execution path rather than relying primarily on alerts and retrospective monitoring?

Yes, without question. If you’re catching this at runtime, you’re already too late. By the time a monitoring tool flags the action, the action has already run. You’ll have a perfect record of exactly how you were exposed, but no way back to stop it.

The only kind of governance that works on something moving at machine speed is one that evaluates the action before it executes and stops the violation inline. We’d never hand our most sensitive data to a new hire and just hope monitoring caught anything that went wrong. Agents deserve that same discipline, at the same moment the action is about to happen. Not after.

Model Context Protocol (MCP) and other agent-tool interfaces are giving AI systems access to increasingly powerful external capabilities. What new security boundaries need to exist around tool calls, APIs, credentials, and service accounts as enterprises expand what their agents are allowed to do?

The tool call is the new perimeter. Every time an agent reaches for a credential, calls an API, or invokes a tool, that’s a decision point, and most enterprises today have no boundary sitting at that exact point evaluating whether the action should happen. That’s the piece that’s been missing. We see the same blind spot from the outside in — just 37% of security leaders are confident they can even identify where AI is running inside the vendors they already work with. If you can’t see it in a vendor’s product, you’re not going to see it in your own agent’s next move either. The credentials and service accounts underneath all of this also need the same rigor we apply to human access: known ownership, defined scope, regular review. An agent shouldn’t be able to reach for a credential it was never granted just because the credential existed somewhere in its path.

When an auditor, regulator, or customer asks what an AI agent accessed, what decisions it made, and where the resulting data went, what level of traceability should organizations realistically be able to provide? Could agent audit trails eventually become as fundamental as traditional access logs?

On demand, organizations should be able to answer what an agent accessed, what decisions it made, and where the resulting data went. Answering that question by piecing it together from logs after the fact is not enough. The bar is a continuous, tamper-evident record that already exists by the time the question is asked. Right now, the answer to these questions is silence from most companies. This isn’t a gap you can explain away to a customer, and depending on what leaked, it’s not one regulators will accept either.

And yes, I think agent audit trails will become as fundamental as access logs, and soon. We’ve treated ‘who accessed what, when’ as non-negotiable for human systems for years. There’s no reason agents should get held to a lower bar just because a person wasn’t the one clicking. Frameworks like the EU AI Act, AIUC-11, and ISO 42001 are already pushing in that direction. Traceability for agents needs to map to the same controls and evidence logic that already power compliance programs. Treating it as an afterthought is how it gets sidelined.

Looking ahead, do you expect AI agent governance to become a distinct security category, or will it ultimately be absorbed into existing governance, risk, compliance, identity, and cybersecurity platforms? What do you think enterprises will need to have in place before they can safely deploy truly autonomous agents at scale?

Every major technology wave creates its own security wave – cloud created Wiz, endpoint created CrowdStrike – and AI agents are creating one now. Model providers are building consoles and policies for their own platforms, which is useful, but no enterprise runs on one model provider, one coding assistant, and one set of internally built agents. Someone has to govern all of that on one set of policies with one source of evidence, and that’s not a problem any single AI platform is built to solve. It isn’t why they exist. AI agent governance is already its own category, even as it plugs into the GRC, identity, and compliance systems companies already run.

Before enterprises can deploy truly autonomous agents at scale, there are four things they need in place, and most don’t have any of them yet. First is real-time discovery – knowing every agent running, who owns it, and what identity it operates under, the moment it’s created.

Next is policy enforced inline, evaluated before an action executes. Third, enterprises need continuous monitoring for drift, since agents outlive the session that created them and their scope can quietly expand. And last, a tamper-evident record of every decision an agent makes, mapped to the frameworks auditors and regulators actually recognize. That’s the layer we’re building at Drata. Without it, an enterprise deploying autonomous agents at scale is just trusting hope.

Thank you for the great interview, readers who wish to explore AI agent governance, continuous compliance, and controls for insider agent threats should visit Drata.