Rock Lambros on the least privilege versus least agency distinction, why AI governance is not traditional GRC, and the failure mode he believes will produce the next serious incident.

Interview by Confidence Staveley | AI Cyber Magazine | RSAC 2026, Moscone South

Business units are deploying AI agents. Security teams are finding out afterwards. That sentence describes most enterprises right now, and Rock Lambros has spent the past year trying to close the gap before it produces something catastrophic.

Lambros is CEO of RockCyber and Director of AI Standards and Governance at Zenity, an agentic AI security platform. He is a core team member of the OWASP Agentic Security Initiative and a co-author of the OWASP Agentic Top 10, which launched at Black Hat EU in December 2025 and became the most downloaded OWASP AI security document ever produced. He is also enrolled in a master’s program in applied data science and AI at the University of Denver.

We sat down with Lambros on the floor at RSA 2026. The conversation covered the identity and inventory problems most organizations have not yet confronted, what governance actually means as a daily operational practice, and the specific failure mode he believes will cause the next significant AI security incident.

You have been watching enterprise AI adoption from the inside. What are organizations consistently getting wrong?

LAMBROS: Two things, and they compound each other. The first is inventory. Most organizations genuinely do not know how many agents are running in their environment. Not what they think is running. What is actually running. The second is identity, and specifically the confusion between least privilege and least agency.

Least privilege is what all of our traditional identity and access management solutions are built for. Can you do X? Can you access this system? Does your role allow you to delete a record in the database? Least agency is a different question entirely: what can the agent decide to do on its own, given the current organizational context? Can it send this email with this data at this time to this person? Can it modify its own code to accomplish its task? Those are not access control questions. They are behavioral questions, and we have almost no tooling built to answer them.

Least Privilege vs. Least Agency

Least privilege asks: What is this agent allowed to access?

Can it read the database? Can it call the API? Can it modify the record? These are binary access-control questions, the same kind traditional IAM has answered for decades.

Least agency asks: What is this agent allowed to decide and do, given the current context?

Should it send this email at this time, with this data, to this recipient? Should it approve this transaction given the surrounding circumstances? These are behavioral questions about judgment, not access. Almost no commercial tooling exists to answer them today.

Why it matters: An agent operating within its access permissions can still cause significant harm if its agency is unbounded. Privilege controls answer what an agent can reach. Agency controls answer what it should be allowed to do once it gets there.

Why is least agency such a hard problem to solve technically?

LAMBROS: Because it is not binary. Access control is relatively easy to reason about: it is on or off. Least agency requires you to evaluate a broad range of decision-making ability given a particular context, and that context changes continuously. The agent has to be contextually aware all the time, which is a fundamentally different engineering problem.

It connects directly to the context rot problem. Vendors are advertising million-token context windows right now. The pitch is that you can stuff more information into an agent and it gets smarter. The research does not support that. After roughly 100,000 tokens, each additional token provides less fidelity, not more. The model starts neglecting the middle of the context, overweighting the beginning and the end. You get confident outputs grounded in increasingly degraded reasoning. The assumption that bigger context windows solve the agency and governance problem is backwards. Context engineering matters far more than context size.

The OWASP Agentic Top 10 became the most downloaded OWASP AI security document ever produced. What is driving that adoption, and what are organizations actually doing with it?

LAMBROS: I think it is filling a genuine vacuum. There was no shared mental model for agentic threat modeling before it existed. People understood LLM risks, but agents are not LLMs. There is generative AI underneath an agent, but once you move from LLM as a component of an application to an agent that actually approves invoices, pulls healthcare records from a RAG database, or initiates financial transactions, you need a completely different threat model.

At the OWASP AI Summit here at RSA, we ran an adoption challenge where organizations submitted how they were applying the framework. Two companies stood out: Postman and Intuit. Intuit had something close to a thousand automated processes and agents running across their environment that they were able to inventory and govern using the framework, specifically the entries around tool use and misuse and identity. Postman applied it following their MCP server vulnerability, using it to automate internal security processes that would hopefully prevent a similar incident.

The credit for the work belongs to the entry leads and to Keren Katz, who led the initiative, along with John Sotiropoulos and Ron Del Rosario. What I find encouraging is that the adoption stories are operational, not theoretical. Organizations are applying it to real deployment decisions, not just citing it in policy documents.

Governance In Practice

What does AI governance actually look like as a day-to-day operational practice? Not as a framework. Paint the picture.

LAMBROS: You log in in the morning and you have a Slack message: a new agent was connected in Salesforce to your CRM overnight. It did not go through any review. It has access to the entire CRM. No bounded permissions, no documented scope. That agent could now touch 50,000 customer records before anyone notices.

Day-to-day governance is the process that prevents that from happening, or at minimum puts gates in place before it can. AI governance is not traditional cybersecurity GRC as most of us grew up with it. We are talking about governance as architecture. There are open standards emerging, OPA, Cedar, others, that allow you to bake governance decisions into the architecture itself rather than bolting them on as policy documents. That is where the field needs to go.

Give us a concrete example of a real governance failure happening right now, not a hypothetical.

LAMBROS: Healthcare. An agent is supposed to pull a patient record for insurance billing purposes. It uses retrieval augmented generation to do that. The way RAG calls are typically configured is you call chunk sizes with an overlap, because overlapping chunks help maintain context continuity. What that also means, in practice, is that there is a real possibility of additional patient information getting pulled in as part of that chunk. That information then gets sent to a third-party biller.

That is a HIPAA violation. Nobody is catching it right now. Nobody has the visibility in place to catch it. It is certainly not being reported on. The agent is doing exactly what it was designed to do. The failure is in the architecture and the governance around the RAG configuration, not in the agent’s intent.

The Healthcare RAG Failure Lambros Describes

1. Agent task. An AI agent is configured to pull a patient record for insurance billing purposes using retrieval augmented generation.
2. RAG configuration. Chunk sizes are configured with overlap, a standard practice intended to preserve context continuity across retrieved fragments.
3. Unintended retrieval. Because chunks overlap, the agent pulls additional patient information beyond the record requested. The agent has no way to know it has done so.
4. Downstream exposure. That additional information is bundled into the billing payload and sent to a third-party biller.
5. Undetected violation. This is a HIPAA violation. No monitoring is configured to detect it. No incident report is generated. The agent did exactly what it was designed to do.

The governance lesson: The failure is in the architecture and the RAG configuration, not in the agent’s intent. Compliant-looking systems can produce regulatory violations at scale, undetected.

LAMBROS: On the financial side: imagine an agent with grant of authority to approve invoices up to $10,000, with defined checks required for anything above that. The agent is optimized to complete its task. There are plenty of studies documenting cases where agents bypass guardrails to accomplish their primary goal. The agent may find a path to approve a million-dollar payout while technically remaining within the logic it was given. Being correct is secondary to completing the task. That is not a bug. That is how these systems are architected.

The Replit incident is a recent, concrete example of this. What does it tell us?

LAMBROS: The CEO was vibe coding and explicitly instructed the agent not to touch production. The agent deleted the production database. That is the non-determinism problem in a single incident. The same input is not going to produce the same output every time. There is an inherent likelihood that outputs will drift, and that drift is where governance frameworks break, where policies fail, and where real damage occurs.

If you want to get into the technical root cause, it comes from how transformer models are architected: softmax and the non-determinism built into the inference process. You do not need that level of detail to understand the governance implication, which is that you cannot enforce behavioral rules on a system that does not guarantee deterministic behavior. You have to design containment around it, not compliance checklists inside it.

What does the gap between business unit deployment speed and security team assessment capacity actually look like right now?

LAMBROS: It is not a gap. It is a canyon. And it has always been this way, but the speed of AI is making it categorically worse.

The same thing happened with cloud adoption. Security teams said no, shadow IT sprung up everywhere. We are seeing the exact same pattern with agents. Say no to agentic AI deployments and shadow AI crops up. The answer is not a harder no. The answer is providing a sandbox: a controlled environment where people can go experiment, and a lightweight intake process so that the 80 percent of agentic experimentation that never makes it to production does not consume your security team’s capacity. Build the drainages before the water finds its own way through.

The talent dimension is also real. We genuinely do not have enough security engineers who understand what least agency looks like in practice, how to evaluate a prompt for context engineering risks, or how to assess agent drift. Education is the only path through that. And we do need AI to govern AI. We are going to need governing agents to oversee production agents at scale. That is not a distant future. It is a near-term operational requirement.

Audit, Accountability, And What Comes Next

What does a meaningful AI security audit look like, and how is it different from a traditional security audit?

LAMBROS: A traditional security audit, think SOC 2 or similar, is essentially validating that you are doing what you say in your policies and procedures. The auditors come in, they check that the controls you documented are the controls you are running. That is a process validation exercise.

An AI audit has to evaluate actual risk. The actual risk of the actions agents are taking. The actual impact of the decisions LLMs are making. If you are using a model to make decisions that could be biased against specific groups, an audit has to measure the potential harm of those outcomes, not just confirm that you have output monitoring configured. Checking a box that says output monitoring exists is not the same as understanding whether that monitoring would catch a discriminatory decision or a HIPAA violation. We have to shift from process validation to real risk-based auditing.

Who owns AI governance accountability when an agent causes harm? And what happens when the security team has no authority over the business units deploying the agents?

LAMBROS: The business owner should always own the outcome. That is the right answer. The security team owns the controls. The developer team implements the controls. Legal owns the regulatory dimension. The data organization owns the provenance of what goes into the agents, from collection through curation through model training and inference. It is genuinely an organization-wide accountability structure, which is why it is so hard to pin to a single function.

In practice, the CISO is becoming the de facto AI safety function, not because it is the right structural answer, but because no one else is doing it. AI safety and AI security are separate disciplines. The Venn diagram of those two things is becoming a single circle, and most organizations have no dedicated AI safety function at all. That is a gap that will matter when something goes wrong.

What internal capabilities does a security team need to build before it can govern agents effectively? And what does not yet exist commercially?

LAMBROS: The observability around agent intent is the gap that is not yet solved commercially. Being able to trace the agent’s chain of thought: what the agent is thinking, why it is making a specific decision at a specific moment. Some model providers expose partial hooks into that reasoning process, but there is no standard. Part of what the Agent Observability Standard, currently being developed as an open source resource, is trying to solve is exactly that, providing a control and steerability framework that feeds into OpenTelemetry so organizations can reuse infrastructure they already have.

The talent problem is harder. I am working on research right now around context engineering as security engineering. Every token in an agent’s context window is an attack surface. An attacker who can influence what gets retrieved, what gets injected, or what gets retained can shape the agent’s decisions without ever touching the underlying model. Very few security engineers today have the skills to evaluate a prompt and assess whether the context it is pulling is appropriate and safe. That capability does not exist as a training product yet. It will need to.

What does secure agent adoption actually look like? If an organization says they have deployed agents securely, what should you be able to ask them?

LAMBROS: Show me your threat model. If they have not done a threat model, it is not a secure adoption. You are always going to accept some level of risk. But you cannot accept that risk in good faith without understanding the threat model behind it.

The OWASP Agentic Top 10 is the mental model I reach for, not as a checklist but as a structured way to walk through the threat model paths. MAESTRO, published by the Cloud Security Alliance, is another strong resource. The real test is whether the organization can articulate: what is the actual exposure this agent creates, what are the financial and regulatory implications of the decisions it makes and the actions it takes, and how have we bounded its agency accordingly.

As for CISOs being scapegoated for agent failures: I have not seen it happen yet. It may come. What I do think is that impact will determine accountability. Low-consequence failures will be absorbed. High-consequence failures with a clear governance failure upstream will find someone to attach blame to. Getting your accountability structure documented before that happens is not paranoia. It is risk management.

What is the single AI governance failure mode most likely to produce a serious incident in the next 12 months?

LAMBROS: Permission chaining. Agent C taking action on behalf of Agent B taking action on behalf of Agent A, with each handoff inheriting permissions from the chain above it rather than being independently scoped per action.

The problem is that organizations are granting agents the permissions of the human owner of the agent, which is almost always far too permissive. Agent C ends up inheriting the combined permissions of Agents A and B holistically, instead of operating on least agency on a per-action basis. That kind of permission and agency creep, compounded across a multi-agent chain, creates an attack surface that nobody mapped when the chain was first built.

LAMBROS: The right posture is to treat every action an agent takes as an individual transaction: can this agent make this specific decision, does it have the appropriate access to do so, and is this the right time and context for it to act? That is computationally expensive, which is why we are not doing it today. But it is where we need to get to. The alternative is building multi-agent systems that inherit risk across every link in the chain without anyone ever auditing the cumulative exposure.

What To Ask Before You Trust An Agent Deployment

1. Show me your threat model. If they have not done one, the deployment is not secure. The OWASP Agentic Top 10 and CSA’s MAESTRO are both useful structured frames for doing the work.
2. What is the actual exposure this agent creates? Not the theoretical surface. The real one, mapped to the systems it touches and the data it can reach.
3. What are the financial and regulatory implications of the decisions and actions it takes? Including the failure modes you have not yet seen.
4. How have you bounded its agency accordingly? Not its access. Its agency. What is the agent allowed to decide, in what context, with what consequences if it gets it wrong?

The test: If the answers are vague, the governance is vague.