AI Agent Security: The Real Risks and How Enterprise Buyers Should Evaluate Vendors

AI agent security is not just about the model

Most AI security discussions start with the model: prompt injection, hallucinations, data leakage, unsafe outputs and model behavior. Those risks matter. But once an AI system can take action, they are no longer the whole security problem.

An agent that can read internal information, update a record, send a message or trigger a workflow creates a broader operational surface. The security question becomes less about whether the model is safe in isolation and more about what the complete system is allowed to do.

For enterprise buyers, AI agent security should therefore be assessed across identity, permissions, retrieval, tools, actions, approvals, auditability and deployment. A model can be excellent and the overall system can still be badly governed.

The first question: what can the agent access?

An enterprise agent may connect to documents, email, Slack, tickets, calendars, CRM records, databases and other company systems. The more useful the agent becomes, the more important the access boundary becomes.

The first review should map the sources an agent can reach and distinguish between information required for a particular workflow and broad access granted simply because it is convenient.

This is the principle of least privilege in agentic form: an agent should have the minimum access necessary to complete its job.

Why service-account access is a different security model

One of the easiest ways to simplify an integration is to give the agent a powerful service account. That can also create a serious security problem.

If the service account can see more than the user requesting the task, the agent may become an unintended path around existing access controls. The agent could answer a question or retrieve a document that the requesting user could not access directly.

A stronger model ties agent access to the initiating user and the permissions already enforced by the source systems. That means the AI layer does not become a new, broader identity with a completely separate view of the company.

Permission-aware retrieval matters

How Libra handles permission-aware access

Libra’s permission-aware retrieval approach is designed to inherit access from the source systems a company already uses rather than create a separate parallel permission model. In practice, the same request should be evaluated against the user’s existing access, not against a broader service identity created for the AI.

This is one of the areas where an enterprise buyer should test Libra directly: use users with different permissions, ask the same question and confirm that the results respect those differences.

Enterprise permissions are not static. People join teams, move roles, lose access, gain access and change projects. A permission model that only reflects the state of the index at the time data was ingested can become stale.

Permission-aware retrieval means access is checked when information is requested, using the permissions already established by the connected source systems.

This matters because the question asked of an AI system can be identical for two people while the correct answer differs because their access is different.

For enterprise buyers, this is a useful test: give two users with different access the same question and see whether the agent respects the difference.

Reading data and changing data are not the same risk

A security review should separate read access from write access.

Reading a project document may be relatively low risk. Updating a customer record, changing an approval state, modifying a financial record or sending an external email may have much higher consequences.

This suggests a more useful permission model for agents: not just “Can the agent use this tool?” but “What can it do inside this tool?”

• Read: retrieve information needed for a workflow.
• Prepare: create drafts or recommended changes.
• Write: make changes to a connected system.
• Execute: trigger a consequential workflow or external action.

These levels can be governed differently rather than treating every tool connection as equivalent.

Human approval is a security control, not a failure of automation

There is a temptation to treat approval steps as evidence that an agent is not sufficiently autonomous. In enterprise workflows, the opposite can be true.

Approvals are useful when the consequence of an action is high but the mechanics are still automatable. The agent can do the research, prepare the update and assemble the draft. The person can approve the final external action.

The objective is not to create a human checkpoint for every tiny step. It is to place human attention where the consequences justify it.

A good enterprise agent therefore needs configurable action boundaries: some tasks can be executed automatically, while others require review.

Prompt injection is only one part of the problem

Prompt injection and malicious instructions are important risks because connected agents can encounter untrusted content inside the systems they read.

But even a system that handles those attacks well can still be unsafe if the agent has excessive permissions or unlimited write access.

For example, imagine an agent that is perfectly good at detecting malicious instructions but can nevertheless access every internal document and send any external email without approval. The security model still has a large blast radius.

The broader lesson is that model-level defenses and system-level controls are complementary. Enterprises need both.

Auditability: can you reconstruct what happened?

A traditional software action often has a clear source: a person clicked a button in a known system. Agentic workflows can be harder to reconstruct because one request can result in multiple tool calls across different systems.

That makes auditability especially important.

A useful audit trail should help answer:

• Which user initiated the task?
• Which systems did the agent access?
• What actions did it take?
• Which actions were blocked or rejected?
• Where did a human approval occur?
• What was the final outcome?

Auditability is not only useful for security teams. It is also useful for operators debugging failed workflows and managers trying to understand where an agent is creating value.

Deployment is part of the security model

Libra deployment options

Libra supports managed cloud, private VPC and fully self-hosted deployment for enterprises. The choice is not presented as a matter of convenience alone: it affects infrastructure ownership, data control and how the platform fits into an organization’s existing governance model.

For teams with stricter infrastructure requirements, Libra describes self-hosted Enterprise deployment in which the full services stack can run inside the customer’s own environment. That makes deployment part of the security conversation rather than a separate procurement checkbox.

Where the system runs can change the organization’s risk profile.

Some companies are comfortable with managed cloud. Others need a private VPC or fully self-hosted deployment because of governance, infrastructure or data-handling requirements.

That means deployment flexibility is not just a procurement feature. It is a security architecture decision.

The right question is not simply “Does the vendor support self-hosting?” It is “Which components run where, what data crosses boundaries, and which security controls remain under our control?”

Data residency and data control

Data residency requirements are often discussed as a hosting question, but in an agentic architecture they also affect where indexed content, context and execution systems operate.

An enterprise should understand which environment contains its data, which services process it, and how the chosen deployment model affects the organization’s ability to control that environment.

Managed cloud, private VPC and fully self-hosted deployment can therefore represent different points on a control spectrum. The correct choice depends on the organization’s requirements rather than on a universal rule that one deployment model is always safer.

A practical AI agent security review

How to evaluate Libra in a security review

The right way to evaluate Libra is the same way you should evaluate any enterprise agent vendor: ask it to demonstrate the controls. Test permission behavior with users who have different access, review the approval boundary for consequential actions, inspect the audit trail for a multi-step workflow and understand where the system runs under each deployment option.

Libra’s security story is strongest when these controls are considered together: company context, permission-aware retrieval, governed actions, approvals, auditability and deployment flexibility.

Enterprise buyers should ask vendors to demonstrate the controls, not just describe them in a security document.

• Show the same question asked by two users with different source-system permissions.
• Show which information the agent is prevented from retrieving.
• Show which actions can happen automatically.
• Show which actions require explicit approval.
• Show the audit trail for a multi-step workflow.
• Show the failure path when a tool rejects an action.
• Show where the system and indexed data run under each deployment option.
• Show how administrative access is separated from user access.

The real enterprise security model

Security for AI agents should not be reduced to a checklist of model vulnerabilities. It is the combined behavior of the model, identity layer, retrieval system, tools, permissions, approval rules, audit trail and deployment environment.

The most useful AI security architecture is therefore not the one that promises zero risk. It is the one that makes the risk boundaries visible and enforceable.

That is what enterprises should look for when they move from AI experimentation to agents that can operate inside real business workflows.