Agentic AI refers to AI systems that can independently plan, decide, and act toward a goal across multiple steps, often invoking tools, APIs, or other systems without continuous human prompting. Unlike traditional generative AI—which produces content in response to a user prompt—agentic AI systems execute workflows, make decisions based on context, and adapt their behavior dynamically over time.

The critical difference is agency. Generative AI is reactive; agentic AI is proactive. When an AI system can autonomously trigger actions—such as sending emails, modifying records, executing transactions, or orchestrating other systems—it effectively becomes a non-human actor and potential insider threat.

Before deploying agentic AI in a business context, ask:

• What authority will this agent have? Can it only read data, or can it modify systems, move funds, or initiate communications?
• What decisions can it make without human approval? Where are the guardrails, and how are they enforced?
• What systems can it interact with? Each integration expands the blast radius of a system failure or compromise. How safe is it?
• How will its behavior be audited and monitored? Can auditors observe what the agent is doing, why it is doing it, and the input used?
• What is the failure mode? How do you stop it if it becomes a threat?

After all these questions have been answered, complete a risk assessment that aligns with the National Institute of Standards and Technology’s AI Risk Management Framework. Individually assess all elements of the agentic AI solution, as well as the sum of all parts, prior to deployment and regularly thereafter.

Identification, Authentication, and Authorization

Agentic AI will have a unique risk profile in your Identify and Access Management (“IAM”) system. At minimum, address these three elements:

• An agent must have a unique, persistent identity distinct from developers, users, or service accounts. Avoid shared or embedded credentials, as they magnify risk in agentic deployments.
• Agents should authenticate using strong, non-interactive mechanisms (e.g., short-lived tokens), with no static passwords or keys baked into prompts or code.
• Least privilege is essential. Constrain agents with fine-grained, task-specific permissions, not broad system access. Granting excessive permissions leads to systemic risk. An agent should never have more authority than the narrow task it is performing at that moment.

Security Risks and Mitigations

While the full scope of systemic risk is too broad for this blog post, here are five high-level risks that must be mitigated when considering an agentic AI rollout:

1. Excessive autonomy enables agents to take unintended actions with real-world impact. Enforce human-in-the-loop controls for high-risk actions.

2. Prompt injection and manipulation can allow external bad actors to force agents to override safeguards. Adopt a secure development framework such as the Open Worldwide Application Security Project’s and perform vulnerability testing at regular intervals.

3. Data leakage and oversharing risks allowing agents to exfiltrate sensitive data during task execution. Limit access only to appropriately classified data and filter output.

4. Lack of accountability will result in systemic issues and untrustworthy AI. Require immutable logging, decision traceability, and clear ownership for each deployed agent.

5. Unmanaged supply chains risk allowing the use of unapproved tools, vulnerable plugins, undocumented APIs, or unfit or hackable models. Review all system dependencies on a regular cadence and restrict interactions to vetted and managed tools and vendors.

Contracting Agentic AI

As expected, technological advancements are outpacing contracting and the law. Best-in-class contractual provisions today may be obsolete in 12-24 months, if not sooner, and even if not, at least for the near term, it will take a village to operationalize and enforce the contractual mandates. Further, most contracts are filed away, never to be seen again unless a dispute develops or the parties are reviewing contract termination logistics. Not revisiting on a regular cadence the security (and other) terms in an agentic AI contract creates substantial risk. Below are a few mitigation options.

While specificity is usually preferable, for the time being it may be worthwhile to leverage more general language, such as compliance with laws (which will, of course, evolve over time and move somewhat in lockstep with the technology). Specific protections outlined above complement the general “compliance with laws” language and serve as the foundation to a mutual operational understanding.

In the near term, consider spending more time negotiating independent third-party audit clauses, for both the developer and the deployer, to help ensure that both parties are receiving the bargained-for protections. An audit in 2031 may look quite different than one in 2026, but at least you will have established the foundation and expectation for confirming mutual compliance.

Most importantly, best-in-class contractual provisions for agentic AI may, given the nature of the technology, and in particular the need to actively monitor and manage it, create a Potemkin village issue. In particular, the contracting party ostensibly benefiting from the robust language may be lulled into a false sense of security. Put otherwise, best-in-class language without the requisite security and operational resources to monitor and manage the salient aspects of the agentic AI solution could be a recipe for disaster. The deployer will need to, among other things:

• Constantly communicate with the developer,
• Learn about model updates and any other changes implemented by the developer that could impact the performance and behavior of the agentic AI solution,
• Validate all integrations,
• Know how to disable the agent if it crosses certain lines,
• Request appropriate documentation from the developer to perform legally mandated risk assessments, and
• Ensure that the logs provided by the deployer are timely, sufficiently granular, and actionable.

The contract should include “hooks” for these activities that require the developer to reasonably comply. In addition, the contract should permit both the developer and deployer to shut an agent down immediately if it presents a safety risk or on short notice if it crosses certain thresholds or operates outside preset guardrails. Deployments will need to factor “kill switch” scenarios into operational continuity, and deployers will need to work closely with developers, at least until expectations harden and the engagement becomes more routine. Conversely, the developer will need to dedicate considerable resources in order to minimize failure risk and help ensure successful deployments. Lastly, the developer and deployer will want to regularly (at least annually) review the AI contract to help ensure that it is meeting their needs and addressing emergent risks.