How to Secure AI Agents and Govern Agentic AI in the Enterprise

Securing AI agents starts with controlling what they can access at the source. Prompt guardrails can shape behavior, but identity, authentication, and authorization determine what an agent can actually retrieve or act on. Governance then has to carry those controls into production, with clear limits on acceptable risk and a way to revisit security decisions as conditions change. 

Those are some of the questions Adrian Salas, CISO at a leading healthcare workforce technology company, works through in the fourth episode of Simform’s Enterprise Cloud and AI Forum podcast. His perspective comes from more than two decades of security work across healthcare, fintech, crypto, and other regulated environments. 

Control access where the data lives. An agent should only be able to retrieve information that its authenticated identity is authorized to access, regardless of what a user manages to ask through a prompt. 

Adrian describes a conversation around a healthcare use case where a user operating as one role was able to prompt for information intended for another. The rules around the agent said that information should have been restricted. 

His recommendation was straightforward: “work with identity at the source.” 

Give one identity permission to datasets A, B, and C and another permission only to A. A successful prompt bypass may change what the agent asks for, but it should not expand what the authenticated identity can retrieve. 

That distinction becomes important as agents gain access to enterprise search, databases, APIs, applications, and other tools. A behavioral instruction inside the agent is useful. It is a weak place to put the final permission check. 

For teams designing production agents, the security question is therefore partly architectural: if the agent ignores an instruction, what still prevents it from reaching something it should never see? 

Adrian goes further into this idea in the episode, including what goal-oriented agent behavior means for familiar zero-trust assumptions. 

AI governance only carries weight when the controls described in the policy are running in the systems where the agent operates. 

Adrian puts the problem plainly: a company can have an AI program, governance documentation, and a list of controls. The useful test is whether those controls are actually being enforced. 

That could mean checking whether an agent’s access matches its approved permissions, whether sensitive data remains restricted, whether activity can be monitored, and whether stated controls remain active after the system changes. 

Governance built mainly around periodic review struggles here. An agent can make requests and take actions continuously. A control confirmed during an earlier review may tell you little about what is happening in the current environment. 

The same gap appears in Adrian’s discussion of cyber insurance. Security questionnaires can confirm that an organization says it has controls. They do not necessarily reveal enough about the data at risk or the way those controls work in practice. 

For an AI platform moving into production, governance has to show up in architecture and operations. A policy that cannot affect the agent’s behavior or access is difficult to rely on when something goes wrong. 

Shipping does not require pretending every security issue has disappeared. It requires knowing which risk is being accepted, what compensating control covers it, and what event forces that decision back onto the table. 

Adrian does not describe security approval as a permanent yes-or-no decision. 

A team may have a known issue and still move forward with a release. Monitoring, for example, might reduce the immediate exposure enough to act as a compensating control. 

The decision needs a trigger attached to it. 

If activity reaches a specified threshold, the team returns to the original risk and reassesses it. The initial approval does not become an indefinite exception simply because production has already started. 

This gives engineering, security, product, and business stakeholders a clearer basis for release decisions. Everyone knows what has been accepted, why the release can proceed, and what would make the current position unacceptable. 

Adrian’s examples in the episode show how he has used that approach when delivery pressure and security concerns arrived at the same time.

The boundary should follow the consequence of the agent’s access and actions. An agent working with anonymized information can justify a different level of control from one handling healthcare records, financial information, customer data, or production systems. 

Adrian frames this as a question of risk appetite. 

Different companies will draw the line differently. Even the same board member may accept one level of exposure in one organization and reject it in another because the business, data, and consequences are different. 

Leadership therefore needs agreement on a few basic questions: What is acceptable? What is non-negotiable? What can the organization take on, and what can it not? 

Those decisions give AI teams something concrete to design around. Without them, every agent deployment can turn into a fresh argument between speed, security, and business value. 

They also prevent governance from treating every AI use case as equally risky. An agent answering questions from low-sensitivity internal content should not automatically inherit the same review path as an agent capable of acting on regulated data. 

For organizations building an Agentic AI strategy, these boundaries belong in the design of the system, not in an approval meeting shortly before launch. 

Security findings stall when they arrive as instructions without enough understanding of the engineering problem, delivery pressure, or people expected to make the change. 

Adrian recalls a product release at a previous organization where he found serious security flaws. Telling the developers that the issues needed to be fixed was getting nowhere. 

So he changed how he worked with the team. 

He flew out, sat alongside the developers, worked through the issues with them, and helped get the code into a secure state without missing the delivery deadline. He recalls the group as being more than 50 developers. 

The part worth carrying into AI engineering is not the flight. It is the proximity to the problem. 

Agent security can cut across code, model behavior, identity, data access, APIs, infrastructure, and product decisions. A finding passed from one team to another can lose the context needed to fix it. 

Adrian’s experience was that working with developers at their level changed the relationship as well as the result. Some of those developers were still in touch with him years later. 

The episode has more on how he brings security into product and engineering conversations early enough that it does not become a late-stage remediation exercise.

For teams asking how to secure AI agents, Adrian’s advice points back to one practical test: what authority does the agent have once it starts working? 

A prompt may tell it what it should do. Identity and permissions decide what it can do. Governance should make those limits real in production. Risk appetite determines where the organization is willing to give the agent more room. 

Watch the full conversation with Adrian Salas for his perspective on agent security, governance, cyber risk, and the relationship between security and engineering teams.