Why Standard Procurement Language Falls Short
Most enterprise software contracts were written for applications that read and write data through defined APIs under human control. AI tools, particularly agentic systems that call external tools and take autonomous actions, introduce a different risk profile. An agent can invoke tools, chain actions, and make decisions at runtime without a human in the loop for each step. Standard vendor security addenda, built around uptime, data breach notification, and general access controls, rarely address who or what executed a given action, what permissions that action required, or whether the system enforced those permissions at the moment of execution rather than only at design time.
This gap matters because procurement is the point of maximum leverage. Once a tool is deployed and integrated into workflows, buyers have far less ability to demand architectural changes. NIST's AI Risk Management Framework treats third-party risk assessment and contractual accountability as part of its Govern function precisely because procurement decisions determine what governance is even possible later. A checklist applied before signing is more effective than a security review applied after rollout.
Access Control and Least Privilege
Contracts should require that vendors support scoped, revocable credentials for individual tool calls rather than static, broad-access API keys. This is a direct application of least-privilege principles already codified in NIST SP 800-53's access control family, extended to AI agents that act on a system's behalf. A vendor that can only offer one API key with full permissions for an entire integration cannot support least privilege regardless of what its marketing materials claim.
Buyers should require vendors to describe, in writing, how permissions are scoped per tool, per action, and per agent. This includes whether permissions can be revoked mid-session, whether they expire automatically, and whether the system distinguishes between read and write actions at the permission level. OWASP's guidance on excessive agency in LLM applications identifies unscoped or overly broad tool access as a distinct risk category, separate from prompt injection or data leakage, and it requires its own contractual language rather than being folded into generic security clauses.
Agent Identity and Attribution
An AI agent acting autonomously is not the same as a user clicking a button, but many vendor systems log both identically or not at all. Contracts should require that vendor systems assign distinct identity to autonomous agents, separate from the human or service account that initiated a session. This allows audit logs to answer a basic question: which agent, acting under which permission set, performed a given action.
Without agent identity, incident response and compliance audits default to reconstructing intent after the fact, often incompletely. This is a system-level requirement, not a policy statement, and vendors should be asked to describe the mechanism, not just confirm that logging exists.
Audit Logging and Runtime Policy Enforcement
Audit logging requirements for AI systems need to go beyond system-level access events. Contracts should specify that logs capture tool invocations, permission grants, and the decision point at which a permission check occurred, not just whether a session started. OWASP's guidance on agentic AI threats identifies insufficient logging and unclear tool-invocation boundaries as recurring weaknesses in multi-agent deployments, and CISA's Secure by Design guidance treats auditable logging as a baseline vendor responsibility rather than a premium feature.
Runtime policy enforcement is a related but distinct requirement. Design-time controls, such as documentation describing intended permission boundaries, do not guarantee that those boundaries are checked when a tool call actually executes. Contracts should require that permission checks occur at runtime, immediately before an action is taken, and that vendors can describe or demonstrate this enforcement point rather than only providing policy documents.
Data Handling, Retention, and Subprocessor Disclosure
Vendors should be contractually required to provide a data flow diagram showing where prompts, outputs, and tool-call data are stored, processed, and by whom. This should include specific retention and deletion timelines for logs, embeddings, and any data derived from customer inputs, since these categories are often left undefined in standard data processing addenda.
Buyers should also require disclosure of subprocessors and third-party foundation model dependencies. Many AI products are built on top of models the vendor does not own or fully control, and NIST's Generative AI Profile identifies third-party component risk as a distinct category. A contract that only names the primary vendor as a data processor, without disclosing the underlying model provider, leaves a gap in the supply chain that procurement cannot assess.
Evaluation Criteria and Tradeoffs
Vendors that support enterprise-grade least privilege and auditability typically can answer procurement questions about access scoping and logging with specific technical detail rather than general compliance language. A vendor that responds to a question about tool-call permissions with a reference to its overall security certification, rather than a description of how permissions are scoped, is signaling that the underlying architecture may not support the level of control being requested.
There are tradeoffs to acknowledge. Requiring granular access scoping and runtime enforcement can add integration complexity and may narrow the field of vendors who can meet requirements today, since the Model Context Protocol and similar standards for tool-call governance are still evolving and have changed multiple times in the past year. Buyers should account for this by requiring contract language that references the intent of the control, such as least-privilege tool access, rather than a specific protocol version, so that requirements remain enforceable as standards mature.
Procurement note
Request contractual audit rights. Self-reported compliance with access control and logging claims cannot be independently verified without the ability to review evidence after the contract is signed.