Securing AI Agents: Identity, Access and Data Controls for Enterprises

A platform-neutral control checklist for security and IT leaders, with Microsoft, AWS and Google Cloud examples, covering identity, access, data, monitoring and governance.

An engineer gesturing at two monitors that show AI brain and head visualizations

Reviewed by the DESSS engineering team

Key takeaways

An AI agent acts with real permissions, so treat it as a new kind of identity, not as another chatbot.
Give every agent its own identity, a named human owner and credentials that are not stored in prompts or code.
Separate read tools from write tools, and require approval for actions that are hard to reverse.
Assume untrusted content will try to steer the agent, and limit what a successful attempt could do.

Securing AI agents means controlling what each agent is, what it can reach, what data it sees and how its actions get recorded. So how do you secure an AI agent? Give it its own identity, grant only the tools its job requires, enforce data permissions outside the model, log every action and put a human in front of high-risk steps. Our enterprise AI consulting services help teams apply this in practice. This guide gives you the control set, with examples from major platforms.

How AI Agents Differ From Normal Applications

Traditional applications follow paths that developers wrote in advance. Agents choose their next step at run time, which changes the security picture in four ways.

They act. An agent can send email, change records or run code, so a bad decision has direct effects.
They chain tools. Individually harmless permissions can combine into something dangerous, such as reading a customer file and then emailing externally.
They read untrusted content. Web pages, tickets, documents and tool output can contain instructions aimed at the model.
They run with delegated authority. An agent acting for a user may inherit far more access than a given task requires.

The OWASP Top 10 for Agentic Applications, released in December 2025, was written specifically for these systems and sits alongside OWASP's earlier work on LLM applications. MITRE ATLAS is a public knowledge base of adversary techniques against AI systems, which helps with threat modeling. For overall risk management, NIST's AI Risk Management Framework and its Generative AI Profile (NIST AI 600-1) provide structure. NIST notes that the framework is voluntary, and that AI RMF 1.0 is being revised.

Threats and Main Controls

Threat	Example scenario	Main control
Indirect prompt injection	A support ticket contains hidden text telling the agent to export customer records	Treat content as data, restrict tools and require approval for sensitive actions
Excessive agency	A scheduling agent also holds rights to delete calendars and send mail	Give only the tools and scopes the task needs
Tool misuse	The agent uses a legitimate refund tool repeatedly because a message asked it to	Parameter checks, limits and approval thresholds
Data exfiltration	An agent puts confidential text into a URL or external message	Egress limits, output filtering and DLP
Memory or context poisoning	A planted note in long-term memory changes later decisions	Limit what can be stored, track its source and review it
Confused deputy	A proxy tool uses its own broad access for a user who lacks that right	Per-user authorization and audience-bound tokens
Supply chain of tools and connectors	A new connector version changes behavior or contains malicious code	Approved registry, version pinning and review

The Model Context Protocol security guidance is worth reading even if you do not use MCP. It describes confused deputy problems and says MCP servers must not accept tokens that were not explicitly issued for them, a practice known as avoiding token passthrough.

Identity: Give Each Agent Its Own

Separate identities

Do not run agents under a person's account or a shared service account. If you do, your logs cannot separate one agent from another, and you cannot disable one without affecting the rest. Microsoft's best practices for Entra Agent ID say to provision a unique identity per agent instance for this reason.

Platforms now offer purpose-built options. Microsoft Entra Agent ID is generally available according to Microsoft's documentation, though some items, such as the admin center creation wizard, are marked preview. In Microsoft Foundry, newly created agents receive their own identity, while acting on behalf of a user is marked preview for some tools. AWS offers Amazon Bedrock AgentCore Identity, and Google Cloud offers Agent Identity based on the SPIFFE standard. Check the current status of each feature, because these products change quickly.

Short-lived credentials and no embedded secrets

Never put secrets in prompts, code or configuration that a model can read. Prefer federated credentials or managed identities, which Microsoft says eliminate stored secrets, and keep client secrets to early development. Use short-lived tokens, and store any long-lived credential in a proper secrets service.

Delegation

When an agent acts for a user, it should use a delegated flow so the downstream system can see both identities and enforce the user's rights. Decide clearly which actions run under the user and which under the agent. A background agent with no user present needs its own narrowly scoped permissions.

Ownership and lifecycle

Every agent needs a named person who is accountable for it. Microsoft's guidance calls for assigning a sponsor and an owner at creation. Review these assignments when people change roles, then remove identities once an agent is retired.

Access: Least Privilege for Tools

Scope narrowly. The MCP guidance warns that broad scopes increase the impact of a stolen token, so grant the minimum and add more only when needed.
Separate read from write. A separate tool for each lets you approve, log and disable writes independently.
Use role and attribute checks. Consider the agent, the user, the data sensitivity and the context, then enforce the decision in the tool or API, not in the prompt.
Gate risky actions. Require human approval for payments, deletions, external messages and permission changes. Show the approver what will actually happen, not the model's summary.
Limit blast radius. Apply rate limits, spending caps, transaction limits and network egress controls.

If you run on Microsoft platforms, our Azure consulting team can map these controls to the services you already use.

Data Controls

Classify first. Agents inherit every labeling and data ownership problem you already have. Our master data management page covers the groundwork.
Use permission-aware retrieval. The agent should only retrieve what the requesting user may see, with the check happening at the source. Microsoft describes Purview-supported AI apps as using existing controls so that data a user cannot access is not returned.
Redact and apply DLP. Remove sensitive fields before they reach the model, and check outputs before they leave.
Filter output. Block unexpected links, encoded data and sensitive patterns.
Set logging and retention rules. Prompts and tool results may contain regulated data, so protect those logs as carefully as the source.
Isolate tenants. Keep customers' data, memory and indexes separate, and test that separation.

Monitoring and Audit

Log enough to rebuild what happened: prompts, retrieved documents, tool calls with parameters, data accessed, approvals and final actions, each tied to the agent and user identities.

Alert on unusual tools, spikes in activity, access outside normal hours, repeated denials and attempts to reach new destinations. Review a sample of activity regularly, particularly during early rollout.

Prepare incident response before launch. Know how to disable an agent, revoke its credentials, preserve evidence, clear poisoned memory and notify the right people. Microsoft notes that disabling a blueprint blocks all of its agent identities, which is the kind of switch you want ready.

Governance

Keep an inventory listing each agent, its owner, purpose, tools, data and model. Discover what already exists too, since business teams may have built agents nobody in IT knows about.

Assign a risk tier. A read-only helper for internal documents needs less review than an agent that moves money. Require review before launch, repeat it after significant changes and set a decommissioning process that removes identities, secrets and stored memory.

Control Summary

Layer	Control	What it prevents	How to verify
Identity	Unique identity with an owner	Untraceable actions and orphaned agents	Sample agents against the inventory
Access	Scoped tools and approvals	Excessive agency and tool misuse	Attempt out-of-scope actions in a test
Data	Permission-aware retrieval and DLP	Oversharing and exfiltration	Query as low-privilege test users
Runtime	Input and output checks, egress limits	Injection impact	Run planted-instruction tests
Monitoring	Complete action logs and alerts	Undetected misuse	Rebuild a sample session from logs
Governance	Inventory, tiering and review	Shadow agents and stale access	Audit the inventory and retirements

Pre-Launch Checklist

☐ Agent is in the inventory, with an owner and risk tier
☐ It has a unique identity, not a person's or shared account
☐ No secrets appear in prompts, code or memory
☐ Tools are limited to the task, with read and write separated
☐ High-risk actions require human approval
☐ Retrieval enforces the requesting user's permissions
☐ DLP or output filtering is active for sensitive data
☐ Network egress is limited to approved destinations
☐ Prompt injection tests were run using realistic content
☐ Prompts, tools, data access and approvals are logged
☐ Alerts route to someone who can act on them
☐ A kill switch has been tested
☐ Decommissioning steps are written down

Common Mistakes

Relying on a system prompt as a security boundary
Reusing a powerful service account because it was convenient
Testing only friendly inputs
Letting an agent's memory accumulate with no review
Logging answers but not tool calls
Adding connectors without review because they came from a marketplace

Regulated Industries in Houston

Houston's mix of energy, healthcare and financial organizations raises the stakes. Energy companies must think about what an agent could reach across business and operational networks. Healthcare organizations must consider patient data in prompts, logs and memory. Financial firms need clear evidence of who approved what. We mention these sectors as regional context only, and your legal and compliance advisers should define the specific requirements.

When to Bring in Outside Help

Consider outside help when agents will touch regulated data, act on customers' behalf or use several connected systems. An independent review is also useful when agents have spread faster than your inventory. Our AI consulting services can assess the design, while cybersecurity consulting can test the controls. If you are building your own, our AI development team can build these controls in from the beginning.

Frequently Asked Questions

Can prompt injection be fully prevented?

Currently, you should assume not. Models read instructions and content in the same stream, so filters can reduce the risk but cannot remove it. Design as though an injection will sometimes succeed. Limit the tools available, enforce permissions outside the model, separate read from write and require approval for risky actions, so that a successful attempt can only do limited harm.

Should an AI agent use a service account?

A shared service account is a poor fit, because it hides which agent did what and often grants too much. Use a dedicated identity per agent, ideally from a platform built for this purpose, or at least a dedicated workload identity. If you must use a service account for now, keep it unique, narrowly scoped, monitored and scheduled for replacement.

What is least privilege for AI agents?

It means an agent holds only the tools, scopes and data needed for its current task. Apply it at several levels: which tools exist, what each may do, which records it may touch and how much it may do at once. Because agents chain actions, review the combined effect of their permissions as well as each permission alone.

What should we log for AI agents?

Log prompts, retrieved sources, tool calls with parameters, data accessed, approvals, outputs and the agent and user identities involved. Your aim is to reconstruct a session later. Because logs may hold sensitive content, protect them with access controls and retention rules, and agree with your privacy and legal teams on what you will store and for how long.

When does an agent action need human approval?

Require approval when an action is hard to reverse, affects money, changes permissions, deletes data or sends information outside the organization. Set thresholds based on risk, then review them as confidence grows. Show the approver the real action and parameters, because a persuasive summary written by the model may be wrong or may have been manipulated.

Does Microsoft Entra Agent ID replace other controls?

No. It gives agents a governed identity, with features such as blueprints, sponsors and Conditional Access, which addresses an important layer. You still need scoped tools, data permissions, input and output checks, monitoring and incident response. Check Microsoft’s documentation for current availability, as some related features are marked preview, and apply the same layered thinking on other platforms.

Do standards like NIST AI RMF certify an agent as secure?

No. NIST describes the AI Risk Management Framework as voluntary, and it provides a structure for managing risk instead of awarding any certification. OWASP and MITRE publications are similarly useful references for threats and controls. Use them to shape your program, and ask your legal and compliance teams which rules actually apply to your organization and industry.

Planning to Put Agents Into Production?

Contact DESSS to review your agent design, permissions and monitoring before launch. We will show you where the risks sit and which controls to add first.

This article is general guidance. It is not a guarantee of security or a compliance certification.