How to Address Security Risks Before Deploying Agentic AI

If your pilot agent is resolving IT tickets faster than ever, leadership is probably getting ready to ask when it’s going to production (if they haven’t already).

While excitement may be high, what leadership may not be privy to is exactly how deep that agent is able to go in terms of provisioning access, modifying HR records, and submitting approvals on behalf of your organization’s employees, at machine speed.

That's a different kind of risk than anything a standard chatbot created. According to Google Cloud's 2025 ROI of AI Study, which surveyed more than 3,400 senior leaders across 24 countries, data privacy and security have become the top concern organizations weigh when choosing an AI provider — perhaps something your leadership has overlooked in its excitement over your pilot agent.

Agentic artificial intelligence itself isn’t the problem, though. Traditional security wasn't written for systems that plan, take action, and execute across your most sensitive platforms, which brings its own set of risks.

This guide covers the highest-impact risks in agentic workflows, the controls that can help address them, and how to build a deployment model your security team is able to stand behind that also satisfies your leadership team.

How agentic AI changes the security model

A standard AI assistant can generate text. An agentic AI system is able to reason about a goal, make a plan of attack, and take a sequence of actions to complete it, often without a human in the loop at every step.

That moves the risk away from what the model says and toward what it does.

It’s like a chain. The agent can receive a request, pull relevant context, create a plan, call one or more tools (APIs connected to your other systems), and log the result. Each link in that chain is an enforcement point where controls either exist… or don't.

For example, an employee in Microsoft Teams asks an agent to update a benefit election in the HR system. The agent can then retrieve the employee's profile, confirm the change is within policy, and submit the update via an API call. The best case scenario here is that everything works as intended.

The risk, though, is that the agent can retrieve a knowledge base article containing embedded malicious instructions, interpret them as a legitimate request, and execute an action the employee never asked for. That's prompt injection, and in an agentic system, it can produce bad output, as well as take bad actions.

Agents are also able to retain memory across sessions. That's incredibly useful for continuity, but it can also mean that sensitive data or unsafe instructions can overstay their welcome beyond the conversation where they first appeared. Segmenting memory by use case and defining clear retention limits are worth building in from the start.

The top 4 agentic AI security risks

Agentic security risks fall into four main categories. Making your teams aware of each (and where it occurs in the agent lifecycle) can make it much easier to prioritize mitigations before you scale to more use cases or broader adoption.

1. Prompt injection and instruction smuggling

Prompt injection can happen when malicious instructions are put into content the agent reads, then acted on as if they were actual commands.

In a basic AI tool, this risk is limited to simple output/directions. In an agentic system, it's a much bigger problem, because the agent is able to act on those instructions across other tools and systems.

Here are a couple of examples of what that might look like:

IT scenario: An agent retrieves a knowledge article to resolve a ticket. That article contains a hidden instruction directing the agent to grant the submitter admin access. The agent incorporates it into its plan and calls your IAM plugin. By the end, it looks like a legitimate provisioning action took place, and now someone who shouldn’t have admin access, does.

HR scenario: A termination request arrives via email. Hidden instructions in the email body redirect the offboarding agent to revoke access for a different employee.

How to reduce this risk:

• Maintain trusted source allowlists (or whitelists) for any content the agent retrieves.
• Parse and sanitize tool outputs before they re-enter the agent's reasoning context.
• Apply policy checks before any action executes, not just before the agent starts.

SOC signal: Alert your team when an agent attempts to override a policy gate, or when a tool call sequence follows a retrieval event in an unusual order. Log which document was retrieved, which tools were called, and the action that was taken.

2. Delegated access and privilege escalation

When an agent acts on behalf of a user, it needs access to the relevant systems. The problem is that access becomes broader or longer-lived than intended, which is a pattern often called permission sprawl.

This tends to happen gradually. An agent might get scoped broadly to simplify setup, and tokens are never rotated. Over time, that same agent might accumulate access no single reviewer would approve all at once.

IT scenario: An onboarding agent is given write access to your identity provider to provision accounts. Its token also picks up group management and role assignment permissions, neither of which is required for its intended function.

Finance scenario: An expense agent inherits credentials that also allow it to modify payment routing data, which is a scope that carried over from a prior workflow and was never removed.

How to reduce this risk:

• Use scoped tokens per tool, limited to the specific operations each agent needs.
• Prefer just-in-time access elevation over permanent broad grants.
• Treat non-human agent identities the same as human team members by inventorying them, assigning ownership, and reviewing them on a regular schedule.

SOC signal: Permission drift over time, new non-human identities in your IAM system, and repeated high-privilege calls outside normal workflow patterns.

3. Data leakage via tools, retrievals, and logs

Data leakage in agentic systems can show up in places teams don't think to look.

A chat transcript is the obvious place to monitor, but sensitive data is also able to creep into retrieval context, tool request payloads, tool responses, and observability logs captured for debugging.

Finance scenario: An expense approval agent retrieves a full compensation record as supporting context, even though only department and manager information was needed. That full record appears in a stream sent to your ITSM tool.

How to reduce this risk:

• Apply data classification-aware retrieval so agents only provide what the requesting employee is permitted to see.
• Redact sensitive fields from tool request and response payloads before they're logged.
• Establish egress controls on tool calls that involve personal or confidential data.

From a governance perspective, your security team should know where agent logs are stored, who has query access, how long they're retained, and if data residency requirements apply. These should be prerequisites for security sign-off from the start.

4. Runaway actions and unsafe automation

Agentic systems can be fast. But speed without checkpoints could create an agent that misinterprets intent and executes a sequence of actions before anyone has the chance to review them.

This matters most for high-impact workflows like offboarding, access revocation, financial approvals, and anything that's difficult to reverse.

HR scenario: An offboarding agent is triggered for "Joe Smith." There are three employees with that name. The agent selects the wrong one, disables their accounts, revokes access, and notifies their manager, all within 30 seconds.

The right Joe is now locked out of systems they actively need, not to mention likely significantly shaken up from worrying they’d lost their job. Meanwhile, the Joe who was supposed to be offboarded still has access to sensitive systems they shouldn't have access to anymore.

How to reduce this risk:

• Require step-up approvals for actions that affect identity, access, compensation, or financial data.
• Set rate limits on sensitive actions so high-volume execution triggers a review.
• Build rollback-ready workflows wherever the underlying systems support reversibility.
• Use dry-run modes in early testing to validate agent behavior without committing live changes.

SOC signal: Rapid sequences of high-impact actions, repeated denied policy checks, and actions taken against targets not included in the original request.

Lock down identity and delegation

Identity is the control plane for agentic AI. Every action an agent takes is tied to an identity, and that identity determines what the agent is permitted to do, what gets logged, and how you investigate when something goes wrong.

In an agentic system, there are three distinct identities to manage:

1. User identity: The employee who initiated the request

2. Agent identity: The agent itself, which needs its own credentials to authenticate with tools

3. Service identity: The API or system being called on behalf of the user

Keeping these separate is what allows you to answer the audit questions of, “Who authorized this?” and, “What identity actually executed it?”

Start with read-only access. Add write permissions only for specific operations the agent actually needs. For example:

• Reset password: Allowed
• Change group membership: Gated
• Assign admin role: Requires human approval

The principle of least privilege is the goal, here. Use time-bound elevation for sensitive tasks instead of permanent broad grants, and apply separation of duties so the person requesting an action isn't also the one approving it.

Add execution guardrails

Preventive controls are important, but no prevention strategy is perfect. Execution guardrails can help reduce blast radius when something slips through, which are enforceable at three points in the agent lifecycle: before the tool call, before the commit, and after the commit (for monitoring and rollback).

Tool allowlists and policy enforcement

Define which tools each agent is allowed to access. Then, within each tool, define which specific operations are allowed. A procurement agent might create a purchase request draft, but not be able to submit it for approval without a policy check.

Policy enforcement points can help evaluate intent, context, and permission before a tool actually executes anything. This is a real-time gate at the moment of action, bringing in human review where it may be needed.

Approvals, rate limits, and rollback

Some actions, however, should almost always require human confirmation:

• Access or role changes
• Spend above a defined threshold
• Employee terminations or offboarding steps
• Data exports involving personal or confidential information

Rate limits can help add a second layer. Even when an agent has permission to act, a high volume of similar actions in a short window is able to trigger a human review before anything is committed. Rollback paths need to be documented and tested, as well. Undoing an agent-driven action should be just as well-defined as the process for performing it.

Build in auditability from the start

When a human takes an action in a system, there's usually a trail. When an agent takes an action, that trail only exists if someone built it in.

A detailed audit trace for an agent workflow should include:

• The original user request
• Which context sources the agent retrieved, and from where
• The reasoning steps the agent took
• Every tool call made, with inputs and outputs
• The final committed action and any approval reference attached to it

Correlation ID, delegated identity, tool operation name, target object, and approval reference are your fields to standardize across logs to help with any audit investigations.

For SOC teams, the most useful signals generally include unusual tool-call frequency, new tool usage not seen in prior sessions, repeatedly denied policy checks, and attempts to access restricted data classes.

Finally, log retention should align with your compliance policy, and access to logs containing sensitive data should be restricted and, itself, logged.

Strengthen agentic AI security with Moveworks

Agentic AI inherently comes with vulnerabilities, but putting in controls from the start can help make your deployment auditable and governable. Moveworks is built with that model in mind.

The Moveworks AI Assistant is the employee-facing feature for requests, like Slack or Teams. This is where employees can ask questions, kick off workflows, and get things done. Agent Studio is where your team can build, govern, and deploy your agents and plugins that power those experiences.

How can Moveworks help address the risks covered in this article?

• Prompt injection: Moveworks Enterprise Search is permissions-aware, meaning agents are only able to retrieve content the requesting employee is authorized to see. That can limit the attack surface for instruction smuggling through retrieved context.
• Privilege escalation: Agent Studio supports scoped tool permissions, so teams can define which APIs each agent is able to call and which operations within each API are permitted. Tokens are short-lived and tied to specific agent identities, which helps reduce lateral movement.
• Data leakage: Sensitive fields are able to be redacted from tool payloads and responses. Employee data is stored in tenant-isolated AWS infrastructure, with encryption at rest and in transit.
• Runaway actions: Policy gates evaluate actions before execution. High-impact actions like identity changes or spend approvals are able to be routed through approval workflows that require human confirmation before anything is committed.

With Moveworks, your teams can have a deployment model, while your security team has a straightforward way to find answers to their questions.

350+ enterprises trust Moveworks for agentic AI deploytment. See how the Moveworks platform can handle compliance, access controls, and audit-ready governance for your organization.