---
Title: "AI agent security: a buyer's guide for enterprise platforms"
Url: "https://devrev.ai/blog/ai-agent-security"
Published: "2026-06-22"
Last Updated: "2026-06-22"
Author: "Neelabja Adkuloo"
Excerpt: "AI agent security spans 3 surfaces – data, action, output. See the 7-criteria buyer's checklist and how to evaluate enterprise AI agent platforms.  "
Reading Time: 14
---

# AI agent security: a buyer's guide for enterprise platforms

Traditional application security was built for deterministic systems that follow fixed logic paths. AI agent security is a fundamentally different problem.

An AI agent perceives its environment, plans multi-step actions, and produces outputs – all autonomously. Each of those stages is an independent attack surface, and a gap in any one of them can compromise the entire workflow.

The strongest solutions implement the **3-surface security model **– defending the data surface, action surface, and output surface – and include mechanisms for prompt injection prevention and hallucination prevention across all three.

For instance, Computer, by DevRev, was built with **permission-aware AI** data access, a Safe Actions capability set, and integrated output guardrails to lower the **bolt-on tax** of retrofitted controls.

If you’re wondering whether [AI agents](https://devrev.ai/blog/what-are-ai-agents) are safe, they can be – provided platform architecture, governance, and operational controls work together.

In this article, we’ll unpack a breakdown of each surface, the 7-criteria checklist, and how to avoid the bolt-on tax.

> [!INFO]
> ## What is AI agent security?
> 
> **AI agent security is the practice of protecting autonomous AI systems across the three surfaces they uniquely expose: the data they can see, the actions they can take, and the outputs they produce. Unlike traditional software security, enterprise AI agent governance demands that all three surfaces are secured by architecture, not patched on afterward.**

## How is AI agent security different from traditional software security?

It’s fair to ask whether [agentic AI](https://devrev.ai/blog/what-is-agentic-ai) security is just LLM security with a rebrand. The answer is no, and the distinction matters when you're choosing infrastructure.

- **Traditional software security was built to protect data**: who can read a file, query a database, or access an API.
- **LLM security extended that to outputs**: preventing a model from saying something harmful, leaking sensitive content, or being manipulated via prompt injection into producing dangerous text.
- **AI agent security must cover both of those concerns and a third**, fundamentally different dimension: actions.
- **Agents don’t just answer questions** – they call APIs, write to databases, send emails, trigger workflows, and make decisions across multiple connected systems, often without a human reviewing each step.

That means the attack surface isn't a record or a response. It's an outcome. A successful attack against an AI agent doesn't leak a row of data; it executes a chain of actions on your behalf.

**Key distinctions among traditional software, LLM Q&A, and AI agents:**

| Category | Traditional software | LLM Q&A | AI agent |
| --- | --- | --- | --- |
| Attack surface | Data at rest and in transit | Model outputs and prompts | Data, outputs, and actions |
| Blast radius | One system or record | One conversation or session | Multiple systems, cascading across workflows |
| Key risks | Unauthorized access, data leakage | Prompt injection, hallucination, PII exposure | Tool abuse, privilege escalation, cascading failures |
| Primary defense | Access controls, encryption | Output filters, input sanitization | All three, simultaneously |

### Why does AI agent security require its own framework?

Because agents can convert a single successful prompt injection into a multi-step attack that reads sensitive records, executes transactions, and publishes results – all without human mediation. That combination raises new risk categories:

- privilege escalation through agent chains,
- denial-of-wallet-like financial abuse, and
- cascading failures when actions ripple across services.

This article focuses on security evaluation. For what AI agents are, see [explainer](https://devrev.ai/blog/what-are-ai-agents). For the best AI agent builder comparison, see [roundup](https://devrev.ai/blog/best-ai-agent-builder).

## The 3-surface security model – a framework for evaluating AI agent security

Every AI agent platform must defend three distinct attack surfaces: the Data Surface (what the agent can see), the Action Surface (what the agent can do), and the Output Surface (what the agent says). Together these form the article’s anchor framework: the 3-surface security model. They should be the primary lens for any vendor review or enterprise AI security discussion.

**The 3-surface security model:**

|  | Data surface | Action surface | Output surface |
| --- | --- | --- | --- |
| What it covers | What the agent can see – files, memory, connected systems, and indexed knowledge | What the agent can do – API calls, tool use, workflow triggers, and system writes | What the agent says – responses, decisions, generated content, and downstream signals |
| Threat examples | Unauthorized data access across tenants; PII exposure through over-permissioned retrieval; memory poisoning via injected context | Tool abuse via manipulated instructions; privilege escalation across connected systems; cascading failures from unchecked multi-step execution | Hallucination in high-stakes decisions; sensitive data leaked through generated text; prompt injection via adversarial inputs |
| Defence mechanisms | Permission-aware AI retrieval; field-level access control | Safe Actions with scope constraints; human-in-the-loop checkpoints | Semantic output checks; audit trails with output logging |
| Computer, by DevRev | Computer Memory enforces permission-aware access | Safe Actions framework constrains tool use to permitted operations | Built-in output guardrails with semantic checks on every response |

### Why does this framework matter for enterprises?

Many vendors defend one surface well (strong data controls) or focus on output alignment, but only platform-level architecture can guarantee consistent protections across all three.

This is the distinguishing test for any AI agent security platform: does it defend each surface independently, or does closing one gap automatically close the others? Architecture-first platforms do the latter. Bolt-on platforms require you to manage each surface as a separate configuration problem – at ongoing cost and complexity.

When evaluating vendors, ask: which surface is weakest, and is that weakness architectural or merely configurable? Architectural weaknesses (e.g., bolt-on output filters or external action adapters without capability checks) incur a bolt-on tax.

> [!INFO]
> [Computer, by DevRev](https://devrev.ai/meet-computer), was built as a single architecture with all three surfaces designed in – Computer Memory enforces the Data Surface, the Safe Actions framework governs the Action Surface, and built-in guardrails defend the Output Surface.

## The bolt-on tax – why does post-hoc AI agent security fail?

Every AI platform makes an architectural choice early: build AI agent security in, or let customers configure it on top. That choice determines who carries the operational load for the lifetime of the deployment.

The bolt-on tax is the ongoing cost of the second option. It shows up as configuration files that need maintenance, exception lists that grow faster than they're reviewed, custom guardrails that break on model updates, and manual audit processes that consume security team hours every quarter. 

None of that work produces capability – it just sustains a baseline that an architecture-first platform provides by default.

By contrast, secure AI deployment is cheaper long-term when RBAC, semantic output checks, and audit trails are inherent to the platform.

![Alt text: The companies building AI agent security infrastructure first will own the next decade of enterprise AI security spend.](https://cdn.sanity.io/images/umrbtih2/production/23c031603614ac9d71232e648ccb77148d951637-816x674.jpg)

_Source: [LinkedIn, 2026](https://www.linkedin.com/posts/feyza-haskaraman-34540a69_ai-agents-break-every-assumption-traditional-share-7356064979889872897-j-vZ/?utm_source=share&utm_medium=member_desktop&rcm=ACoAACLqRRkB9G2jvgcldEUF5lwML6kvXjkqFvs)_

| Aspect | Bolt-on security stack | Built-in security architecture |
| --- | --- | --- |
| Permission model | Manual mappings and custom adapters | Inherited permissions (IdP, Salesforce, Jira) |
| Guardrails | External filters, custom scripts, exception lists | Pipeline guardrails (semantic checks, redaction, model-level rules) |
| Action control | Adapters or separate action brokers with manual approvals | Safe Actions framework with capability-based execution and approval flows |
| Auditability | Manual log aggregation, spotty provenance | Default, structured audit trails linking prompts → actions → outputs |
| Operational cost | High: ongoing rule maintenance and exception handling | Lower: fewer exceptions, less config drift, predictable compliance |
| Risk profile | Higher: missed edge cases, cascading failures | Lower: architectural enforcement reduces human error |

_This query-time enforcement model aligns with zero-trust architecture principles: never trust, always verify._

For enterprise AI agent governance, look for platforms that inherit permissions from your identity provider and existing systems, apply AI guardrails in the processing pipeline, and emit audit trails by default. That shifts labor from your security team to the vendor and reduces compliance friction (fewer exceptions, cleaner SOC 2 Type II evidence, simpler GDPR processing).

> [!INFO]
> Computer reduces the bolt-on tax structurally: permissions flow from your existing systems (Salesforce, Jira, identity provider), guardrails are part of Computer Memory's query pipeline, and audit trails are generated by default.
> 
> **Also read: **[DevRev’s agentic AI: powering human & AI connection](https://devrev.ai/blog/devrevs-agentic-ai)

## How does permission-aware AI control what the agent can see?

The data surface is the foundation of AI agent security. Before an agent can act or respond, it reads – and what it's allowed to read determines the blast radius of everything that follows.

Most platforms handle permissions at ingestion: data enters the system tagged with access metadata, and administrators configure retrieval rules on top. The problem is that those rules live in the AI platform, not in the source system. They drift. They don't reflect real-time role changes. And they require ongoing maintenance every time your identity configuration changes.

**Permission-aware AI** takes a different approach. Instead of re-implementing access control inside the AI layer, it inherits permissions from source systems – your identity provider, your CRM, your ticketing platform – and enforces them at query time, every time. 

Two users asking the same question get different answers, because the agent only surfaces data each user is already authorized to see. That is **role-based access control (RBAC)** applied at the retrieval layer, not the ingestion layer.

![Alt text: Architectural diagram showing AI agent security flow: user query to identity check to computer memory permission filter to grounded retrieval to answer.](https://cdn.sanity.io/images/umrbtih2/production/26cc0a62bb9826817623701bba5bf820e6d28d64-1398x716.jpg)

The practical difference matters most in **multi-tenant** and cross-functional environments. Without query-time enforcement, an agent with broad ingestion access becomes a single point of **AI data leakage prevention** failure: one misconfigured rule exposes data across teams, roles, or customer accounts. With query-time enforcement, the permission boundary moves with the user – no rule maintenance required.

**Data residency** is the other dimension of data surface defence that enterprise procurement teams frequently underweight until it becomes a compliance issue. Where does the agent's memory live? Which jurisdiction processes queries?

Computer, an [AI teammate](https://devrev.ai/blog/what-is-an-ai-teammate), uses **Computer Memory** as its Data Surface control-plane: user identity flows in from existing systems, RBAC and field-level rules are enforced at query time, and only authorized snippets are retrieved into the agent’s context.

> [!INFO]
> Computer Memory stores and processes data with configurable residency controls, so organizations operating under [GDPR](https://devrev.ai/security/sub-processors), HIPAA, or regional data sovereignty requirements can enforce geographic boundaries at the infrastructure level.That design, combined with DevRev’s [security program](https://security.devrev.ai/), lets teams scale agent usage without building a parallel permissions engine or sacrificing enterprise AI governance.

## What does the Safe Actions framework do when an AI agent wants to act?

The action surface is what separates AI agents from every prior category of enterprise software. A chatbot that says something wrong is a support problem. An agent that does something wrong – sends an email, modifies a record, triggers a workflow, calls an API – is an operational one. The blast radius is not a bad response. It is a real-world outcome.

### Why does the action surface need its own defence model?

Defending the action surface requires four properties working together:

- Every action must generate an AI agent audit trail by default – not as an optional logging integration, but as an architectural output of every execution.
- High-risk actions must escalate to a human-in-the-loop checkpoint before they execute, not after.
- Executed actions must be reversible where the downstream system allows it.
- What counts as high risk must be configurable per workflow – a bulk data export in a finance workflow carries different risk than the same action in a sandbox environment.

### Risk-tiered execution: safe by architecture, flexible in practice

Requiring human sign-off on every agent action trades autonomy for brittleness – the agent becomes an expensive form-filler. The right model is risk-tiered:

| Risk level | What happens | Audit trail | Rollback available |
| --- | --- | --- | --- |
| Low | Executes immediately | Logged automatically | Yes |
| Medium | Executes, notifies security team | Logged automatically | Yes |
| High | Pauses for human-in-the-loop approval, then executes | Logged automatically | Yes |

All three tiers write to the audit trail automatically. Rollback hooks are available at every tier where the downstream system supports reversal.

![Alt text: Diagram showing an AI agent security action flow.](https://cdn.sanity.io/images/umrbtih2/production/fea32e26b173f55e532b0fad6ae5c3eb9380f736-1240x816.jpg)

### How Computer's Safe Actions framework implements this

Computer's **Safe Actions** framework implements risk-tiered execution natively. Thresholds are configurable per workflow, not global settings applied uniformly across every agent. For complex, multi-step workflows, [**Agent Studio for Computer**](https://devrev.ai/agent-studio) provides governance tooling at the workflow level: inspect action sequences, set escalation rules, and define rollback behavior per agent, not per integration.

The human-in-the-loop mechanism in Computer is a deliberate architectural control, not a fallback. For [customer service automation](https://devrev.ai/blog/customer-service-automation-software) workflows, a refund above a configured threshold routes to a human reviewer before execution, while the agent continues working on other tasks in parallel. That is what secure AI deployment looks like at enterprise scale: enterprise AI governance that scales with the operation, not against it.

## Output Surface – AI guardrails that defend what the agent says

The Output Surface is the agent's outward response – text, reports, code, emails, messages. Most AI guardrails focus here.

### Why does defending the Output Surface matter?

Defending the Output Surface needs three architectural layers:

| Layer | Mechanism | What it prevents |
| --- | --- | --- |
| Grounded retrieval | Agent responds only from verified, permission-scoped sources | Hallucination – model cannot fabricate outside retrieved context |
| Semantic output check | A validator model reviews the response before delivery | Prompt injection payloads, policy violations, out-of-scope responses |
| Content filter | PII redaction, profanity filtering, response isolation | Sensitive data leakage in generated text, cross-session contamination |

Together these layers mitigate key threats from the [OWASP LLM Top 10](https://owasp.org/www-project-top-10-for-large-language-model-applications/) (including prompt injection).

### How AI guardrails work at each layer: The 3-layer output defence stack

- **Grounded retrieval**: restricts the agent’s context to audited, permission-filtered sources, so answers are grounded in trusted data rather than plausible-sounding fabrications.
- **Semantic output checks**: a small validator model inspects the agent’s response for factual consistency, policy violations, and unsafe patterns before it’s sent.
- **Content filtering**: deterministic rules and redaction policies strip PII, block profanity, and enforce response isolation to keep outputs safe for multi-tenant environments.

> [!INFO]
> Computer, combines grounded retrieval with a validator-model pipeline: retrieval is permission-aware and source-bound, and every response runs through a semantic check before delivery. This multidimensional AI agent guardrails approach reduces hallucinations, blocks prompt injection in outputs, and enforces consistent policy enforcement across all agent responses. The result is output security that’s architectural, not bolt-on.

## Enterprise compliance – what certifications matter for AI agent deployments in 2026?

Five certifications form the enterprise baseline in 2026:

- **SOC 2 Type II** – table stakes for trust and controls over security, availability, and confidentiality.
- **ISO 27001** – infrastructure rigor and ISMS maturity.
- **GDPR / data residency** – required for EU operations and cross-border data handling.
- **HIPAA** – required for healthcare-adjacent workloads and PHI handling.
- **Emerging AI-specific standards** – ISO 42001 and NIST AI RMF alignment (new 2024–2026) for AI agent compliance and enterprise AI governance.

| Certification | What it covers | Who needs it | Computer status |
| --- | --- | --- | --- |
| SOC 2 Type II | Controls over security, availability, confidentiality, privacy | All enterprise buyers | ✅ SOC 2 Type II |
| ISO 27001 | Information Security Management System (ISMS) | Global enterprises, regulated industries | ✅ ISO 27001:2022 |
| GDPR / data residency | EU data protection and cross-border transfers | EU customers, multinationals | ✅ GDPR-compliant, EU data region |
| HIPAA | PHI handling and healthcare compliance | Healthcare and life sciences | ✅ HIPAA-eligible services under a BAA |
| AES-256 at rest | Encryption for stored data | All enterprise buyers | ✅ AES-256 |
| TLS 1.2/1.3 in transit | Encryption for data in motion | All enterprise buyers | ✅ TLS 1.2/1.3 |
| Customer-managed keys | Encryption key ownership and control | Highly regulated customers | ✅ Customer-managed encryption keys |
| ISO 42001 | AI management system (AI governance) | AI-focused enterprises | ⏳ Emerging – alignment in progress |
| NIST AI RMF | AI risk management framework alignment | US federal and regulated sectors | ⏳ Emerging – alignment in progress |

> [!INFO]
> Computer holds the standard enterprise set (SOC 2 Type II, ISO 27001:2022, GDPR) plus HIPAA-eligible services under a BAA, AES-256 encryption at rest and TLS 1.2/1.3 in transit, and multi-region data residency (US, EU). The new question buyers should ask is alignment with ISO 42001 and NIST AI RMF. For details, see [DevRev’s security certifications](https://security.devrev.ai/).

## How to secure AI agents – a 7-criteria evaluation checklist

Use this checklist to separate enterprise-ready AI agent platforms from configuration-heavy alternatives. These criteria map to the 3‑Surface Security Model, the bolt‑on tax, and compliance.

### 1. Permission-aware data access by architecture

The platform enforces access controls at query time (not just ingestion), so agents only retrieve what callers are allowed to see.

**_Red flag if absent:_** data is flattened into one corpus and filtered only at output

_(Computer: permission-aware AI via Computer Memory, scoped to identity and RBAC.)_

### 2. Field-level and multi-tenant isolation

RBAC extends to object-, row-, and field-level access, with strong tenant isolation and data residency options.

**_Red flag if absent:_** no field-level controls or cross-region data leaks.

_(Computer: field-level access control and data residency across US/EU regions.)_

### 3. Safe actions with default audit trails

Every agent action is logged by default with identity, prompt, action parameters, result, and approvals.

**_Red flag if absent:_** actions aren’t traceable or require manual log aggregation

_(Computer: Safe Actions framework, audit trails generated by default.)_

### 4. Configurable human-in-the-loop with rollback

Risk thresholds are configurable; high-risk actions escalate to humans; rollbacks are supported.

**_Red flag if absent:_ **all actions must be pre-approved (brittle) or HITL can’t be configured.

_(Computer: Agent Studio for escalation policies and audit views.)_

### 5. Built-in output guardrails (grounded retrieval + validators)

Responses are grounded in verified sources and run through semantic checks before delivery.

**_Red flag if absent:_** no validator model or content filtering for PII/hallucinations

_(Computer: grounded retrieval + validator-model pipeline for output guardrails.)_

### 6. SOC 2 AI + ISO 27001 + AI-specific framework alignment

SOC 2 Type II, ISO 27001, GDPR/HIPAA support, plus alignment with ISO 42001 and NIST AI RMF for AI agent compliance and enterprise AI governance. Under the EU AI Act, autonomous support agents handling customer decisions may qualify as high-risk systems – making documented framework alignment non-negotiable.

**_Red flag if absent:_** no AI-specific framework roadmap.

_(Computer: SOC 2 Type II, ISO 27001:2022, GDPR; HIPAA-eligible services under a BAA; ISO 42001/NIST AI RMF alignment in progress.)_

### 7. Low Bolt-On Tax – measurable hours-per-month saved

Security is architectural, not bolted on; your security team saves time on config, exceptions, and audits._Red flag if absent:_ heavy reliance on custom adapters, scripts, or manual audits._(Computer: permissions flow from IdP/Salesforce/Jira, guardrails in pipeline, audit trails by default.)_

> [!INFO]
> **See how Computer scores on all 7 criteria.**
> 
> [**Book a 14-day workload demo**](https://devrev.ai/request-a-demo)

## How does Computer, by DevRev, approach AI agents security?

Computer’s architecture maps 1:1 to the **3‑surface security model**. Each surface has a dedicated capability that enforces AI agents security by design, not by configuration.

| Surface | Computer capability | Why it matters |
| --- | --- | --- |
| Data Surface | Computer Memory (permission-aware AI, query-time enforcement, multi-tenant isolation) | Enforces access controls at query time, inherits from source systems (IdP, Salesforce, Jira), and prevents data leakage by returning only authorized slices. |
| Action Surface | Safe Actions framework (default audit trails, configurable HITL, rollback hooks) | Every action is logged; high-risk actions escalate via Agent Studio for Computer; rollback capability limits blast radius. |
| Output Surface | Grounded retrieval + semantic validators + content filtering (AI guardrails) | Responses are grounded in verified sources, checked by validator models, and filtered for PII/harmful content before delivery. |

Compliance & data protection

- SOC 2 Type II, ISO 27001:2022, GDPR; HIPAA-eligible services under a BAA
- AES‑256 encryption at rest, TLS 1.2/1.3 in transit
- Customer‑managed encryption keys
- Multi‑region data residency (US, EU)

This design supports enterprise AI governance by reducing the bolt‑on tax: permissions flow from existing systems, guardrails are built into the pipeline, and audit trails are generated by default. Computer was built as a single architecture for AI agent security, not as a chatbot with bolt‑on controls.

**For details on certifications and security posture, see [DevRev security certifications](https://security.devrev.ai/).**

## Proof of fintech-grade AI agent security in production

The strongest signal that an enterprise AI platform passes a serious security review is not a certification page. It is a production deployment in financial services.

### How BILL chose Computer over Salesforce Agentforce

BILL is a $1.6B fintech processing transaction for hundreds of thousands of businesses. Their security bar is not theoretical. Any AI deployment must pass SOC 2 scrutiny, encryption standards review, data residency validation, and full audit-trail requirements before it touches production.

BILL evaluated Computer alongside Salesforce Agentforce, while running on Salesforce. Computer won on output quality, and reached production in under three months, including BILL's full security review.

| Metric | Result |
| --- | --- |
| Time to production | Under 3 months, including BILL's full security review |
| Queries evaluated during POC | 200,000+ |
| Projected savings | Up to $4.5M in cost savings as deflection scales past 50% |
| Output quality vs Agentforce | Computer preferred; 73% resolution rate during the proof of concept |
| Security review passed | SOC 2, encryption, data residency, audit trails |
| Salesforce coexistence | Yes, deployed on existing Salesforce infrastructure |

> [!INFO]
> If Computer passes a fintech security review at BILL's scale: $1.6B revenue, hundreds of thousands of business customers, financial transaction data, it is built to pass yours. Enterprise AI governance at financial-services grade is not a roadmap item for Computer. It is already in production.
> 
> Read [BILL’s](https://devrev.ai/customers/bill) full story.
> 
> 

## Shouldn't AI agent security come built in, not bolted on?

Your security team should not need to configure safety into the platform.

Enterprise AI security should make your security team's work softer, not harder. Built‑in is the difference.

Computer was built with the 3 surfaces designed in – permission‑aware data access, safe actions, and output guardrails – so governance comes by architecture, not configuration.

[See Agent Studio's governance in action](https://devrev.ai/agent-studio), or

[Read the BILL security story](https://devrev.ai/customers/bill)  
  


## FAQ

### What is AI agent security?

AI agent security protects the three surfaces unique to agents: the data they access, the actions they can take, and the outputs they produce. It’s built on the 3‑Surface Security Model and requires defenses baked into architecture (permission‑aware data access, safe actions, output guardrails) rather than bolt‑on filters added after the platform is built.


### Are AI agents safe for enterprise use?

Yes – when the platform defends all three surfaces by architecture and holds enterprise certifications (SOC 2, ISO 27001, GDPR). BILL's financial-services-grade deployment with Computer (first production in under three months, 200K+ queries evaluated during the POC) demonstrates enterprise safety at scale.


### How is AI agent security different from LLM security?

LLM security defended outputs (what the model said). AI agent security must also defend the Data Surface (what the agent can see) and the Action Surface (what the agent can do). Same model, larger attack surface.


### What is permission-aware AI?

Permission‑aware AI inherits access controls from source systems and enforces them at query time. Two users asking the same question receive different answers based on their actual permissions.


### Can AI agents leak customer PII?

Yes, if the Data Surface is unguarded. Defenses include field‑level access controls, multi‑tenant isolation, PII scanning before processing, and grounded retrieval that excludes restricted fields from agent context.


### How long does it take to deploy a secure AI agent platform?

Built-in security platforms: weeks. Bolt-on configurations: months. BILL reached first production with Computer in under three months - including full security review.