At Veza from ServiceNow, we’ve spent countless hours with enterprise security teams trying to answer a critical question: Who (or what) is allowed to act inside systems, and just how far can they go? AI agents have made that question more urgent and high stakes than ever before.
With AI agents, digital entities are already weaving themselves into the fabric of the enterprise, automating complex workflows and making decisions at machine speed. But with this incredible power comes a profound shift in risk: The central security challenge is no longer about preventing just data loss; it’s about preventing unauthorized autonomous actions as well.
An AI agent tricked into paying a fraudulent invoice, deleting a critical database, or sharing sensitive merger and acquisition plans isn't a data breach in the traditional sense—it's an operational catastrophe and a huge business risk.
Harnessing the power of agentic AI safely requires a blueprint for a new class of identity: agentic identities. This blueprint should be based on a security concept that’s both timeless and more relevant than ever: the principle of least privilege.
Organizations can follow a practical, 11-principle blueprint for implementing this approach for agentic identities, applicable from the first line of code to the final production deployment.
A large language model (LLM) is a reasoning engine, not an authorization engine. Relying on natural language prompts to control an AI agent's permissions is fundamentally insecure. AI agents can easily bypass an instruction such as, "Do not access the payroll database."
What to do: Govern access decisions through predictable, rule-based flows. Use established, deterministic protocols such as OAuth2, an industry-standard framework to manage authorization.
An LLM can propose an action, but a separate, independent, and secure authorization layer must verify an AI agent's identity and issue a tightly scoped access token before the action is executed. The scoped access should grant the agent only the permissions it needs to perform the actions at hand.
Giving an AI agent direct access to a database is a recipe for disaster. It allows the agent to bypass critical business logic, validation rules, and security checks embedded in your application layer. Even worse, allowing an AI agent to impersonate a human user by providing it with the same credentials confuses the actor and what AI agents are doing across your environment.
What to do: Funnel all AI agent interactions with data and systems through well-defined, secure APIs or the Model Context Protocol (MCPs). These interfaces act as gatekeepers, enforcing the business logic that protects your systems.
An AI agent should be able to request an individual customer order through an API and not have to pull the entire customer database—for example, using a command such as “get_customer_order(order_id),” instead of “SELECT * FROM customers.”
As AI agents become development partners, they’ll inevitably write business logic. The progressive approach is not to block this evolution, but to build a framework that makes it safe. The true risk lies not in the AI-generated code itself, but in the absence of automated guardrails to govern it. This helps ensure AI enhances, rather than undermines, your application's integrity.
What to do: Define critical security and business rules as code so they can be checked automatically. All AI-written contributions should pass through an automated checking system before they go live.
In technical terms, it’s a continuous integration and continuous delivery (CI/CD) pipeline. Nothing changes in production unless it’s first been committed to a shared, tracked record, and AI agents shouldn’t have direct permission to deploy code in production.
This frees people to oversee the checks themselves rather than review every change manually.
Standing privileges are a critical vulnerability. An AI agent with persistent access to a system is a constant target. If it’s compromised, its broad permissions can be used by an attacker at any time.
What to do: Grant permissions on a just-in-time basis and only for the duration of a specific task. These short-lived credentials should be scoped as narrowly as possible and automatically revoked the moment a task is completed. This can dramatically shrink the window of opportunity for an attacker to strike or for the AI agent to misbehave later.
AI agents may take risky or unexpected actions in pursuit of their end goals. For compliance, risk triage, and forensic analysis, having an unchangeable record of every action is nonnegotiable.
Investigating an AI agent's activity is nearly impossible when logs are scattered across dozens of disparate systems. If an agent takes a harmful action, you must be able to understand what happened and why. Without a clear audit trail, forensic analysis and accountability are impossible.
What to do: Ingest and correlate native audit trails from all cloud and software as a service (SaaS) applications into a centralized, identity-centric view. This consolidates disparate logs into a unified, immutable record of every resource an AI agent identity accessed. It creates an indispensable forensic trail for rapid incident investigation, root cause analysis, and compliance proof.
Log every privileged action taken by an AI agent in an unchangeable record. This log should capture the full context: the agent's identity, the permissions used, the goal it was pursuing, the data it accessed, and the final outcome.
An AI agent is a new type of identity, like a nonhuman identity or application identity. It should be governed with the same rigor as that of a privileged human administrator. Shadow AI agents deployed without oversight are significant security risks.
What to do: Document a clear owner and purpose for each AI agent before it’s deployed. All associated credentials should be rotated automatically and frequently. When an agent is no longer needed, it should be completely and securely decommissioned by revoking all permissions and deactivating its identity.
In complex workflows, you might deploy multiple AI agents that collaborate to achieve a goal. It's a common mistake to assume that because these agents are part of the same system, they can implicitly trust each other.
What to do: Enforce agent-to-agent authentication. Independently authenticate and authorize every interaction between AI agents. Agent A should treat a request from Agent B with the same skepticism as a request from an unknown, external user by requiring a valid, short-lived, and properly scoped token before proceeding.
An AI agent's power comes from its memory and its ability to maintain context across interactions. However, this is also a prime attack surface. Attackers can poison an AI agent's memory with malicious information, subtly altering its behavior over time.
What to do: Isolate each AI agent's memory and context to its own user session, cryptographically and logically, away from all others. For foundational instructions, use a read-only memory store to help prevent tampering. Sanitize any information before it’s committed to long-term memory.
The most robust security posture is one that’s constantly tested. Given the unpredictable, emergent behavior of AI agents, you cannot wait for an attacker to find your vulnerabilities.
What to do: Go beyond standard unit tests. Have a “red team,” a group that plays the attacker, try to break your AI agents with sophisticated prompt injection, tool misuse scenarios, and complex logic manipulation. Documenting these vulnerabilities and using them to harden your defenses are critical parts of the security lifecycle.
An AI agent that can read or write data is a risk; an agent that can change the structure of that data is another risk entirely. Granting an AI agent the ability to alter database schemas, modify cloud configurations, or change critical metadata can easily result in irreversible damage.
What to do: Deny each AI agent’s identity permission to make structural changes. This includes database commands, such as “ALTER TABLE” or “CREATE SCHEMA,” and privileges to modify cloud infrastructure, such as identity and access management roles or network security groups. These administrative-level permissions should be reserved for humans.
For the most critical and irreversible actions, full autonomy is a liability. A human should serve as the final gatekeeper to prevent a hijacked or hallucinating AI agent from causing irreparable harm.
What to do: Define what constitutes a high-stakes action—for example, initiating a wire transfer above a certain dollar amount, deleting data, or deploying code to production. The AI agent can only propose these types of actions. The request must then be queued for explicit approval by a designated human who has the full context to make an informed decision.
Adopting a security-first mindset for agentic AI doesn’t have to slow down innovation; it actually enables it. Building on this blueprint can provide the guardrails that allow developers to create with confidence and businesses to deploy AI agents into critical workflows.
Securing agentic identities is the key to unlocking the immense promise of autonomous systems, helping to ensure they operate as trustworthy partners in the enterprise of the future.
Find out how ServiceNow can help you take control of risk across every identity type.
