Warning signs include vague terms like broad lawful-use language, no clear statement of who can change safety rules, limited auditability, and no documented continuity path if the model provider changes policy. If the vendor cannot explain how restrictions are enforced and reversed, the control boundary is too soft for serious procurement decisions.
What Discretion Looks Like in an AI Vendor Control Model
Controls are discretionary when the vendor can change, interpret, or waive safety and usage restrictions without a crisp, testable rule set. That is a problem because procurement teams cannot tell whether the promised boundary is enforced by policy, code, or reputation management. If the vendor’s answer depends on who you ask, the control surface is already too soft.
Vague lawful-use language is one of the strongest signs of discretion because it signals intent, not enforcement. The practical test is whether the vendor can point to a specific control boundary, a named owner for rule changes, and a predictable process for rollback or exception handling. If those elements are missing, the buyer is being offered judgment calls rather than control.
A second sign is weak auditability. If the vendor cannot show what was blocked, what was allowed, and why, you cannot distinguish a deliberate policy from an informal operator choice. That matters most when the product is used in regulated workflows, production decisioning, or environments where the buyer needs evidence that restrictions were actually applied.
Signs the Boundary Is Too Soft for Procurement
Soft boundaries usually show up as a mix of ambiguity and reversibility. The vendor may say they enforce safe use, but not describe how restrictions are encoded, who approves changes, or how quickly those changes propagate across tenants, models, or deployments. A serious control should survive personnel change, provider policy shifts, and support escalation without becoming ad hoc.
Another warning sign is when the vendor cannot explain continuity if the model provider changes policy. In that case, your control depends on an external relationship rather than an owned operating model. For procurement, that means the same use case could become compliant, restricted, or silently degraded without a clear change-management trail.
Watch for controls that are described as “best effort,” “as needed,” or “case by case” when the use case requires repeatable enforcement. Those phrases are not automatically bad, but they do mean the buyer should treat the control as advisory unless there is evidence of hard enforcement, logging, and exception governance. In practice, discretionary controls tend to fail at scale because they cannot be reviewed, tested, or inherited reliably.
How Buyers Should Judge Enforcement, Reversal, and Evidence
The right question is not whether the vendor has safety intentions, but whether the control can be validated before contract signature. Buyers should ask for the enforcement mechanism, the change authority, the audit trail, and the continuity path in one coherent answer. If any one of those is missing, the vendor has not yet proved that the control is operational rather than rhetorical.
Look for evidence that restrictions are reversible in a governed way, not by informal support action. A vendor with mature controls can explain what triggers a policy change, who can override it, what evidence is retained, and how customers are notified when the operating boundary changes. That is the difference between a control framework and a promise.
For procurement teams, the most useful benchmark is consistency under pressure. A control is credible when the vendor can show that the same rule applies across deployments, escalations, and product updates without relying on individual judgment. If the answer is “it depends,” ask what documentation, logs, or contractual language makes that dependency auditable.
Risk and Threat Considerations
Discretionary controls create exposure because they are easy to reinterpret after deployment and hard to verify during a dispute. That makes them risky not only for compliance, but also for business continuity, since a policy change or support exception can alter what the system is allowed to do.
Failure mechanism: The vendor’s control boundary relies on informal judgment, undocumented exceptions, or opaque policy changes, so the buyer cannot prove what was enforced at any point in time.
Impact: Procurement can end up with false assurance, weak audit evidence, and an unstable operating assumption that breaks when the provider changes policy, ownership, or enforcement posture.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 addresses the attack surface, NIST SP 800-53 Rev 5 sets the technical controls, and ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Auditability is central when vendor controls may change by discretion. |
| CM-3 — Configuration Change Control | The question turns on who can change safety rules and how changes are governed. | |
| Recommendation — Require traceable logs and reviewable evidence for each control change. Enforce formal approval and testing for any safety-rule change. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Control boundaries must be enforced predictably, not by informal discretion. |
| A.5.23 — Information security for use of cloud services | Vendor continuity and policy shifts are a third-party operating risk. | |
| Recommendation — Define and enforce explicit access and restriction rules. Assess provider changeability and retain continuity requirements in supplier controls. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Soft control boundaries can let authority change without clear governance. |
| Recommendation — Bound who can alter agent or model permissions and safety settings. | ||
Practitioner Guidance
What to verify: Ask the vendor for the exact control owner, the change process, and the audit record that proves enforcement, then test whether the answer is stable across sales, security, and support teams. If those answers differ, treat that as a governance defect, not a communication issue.
Decision rule: If the vendor cannot show how restrictions are enforced and reversed, do not treat the control as procurement-grade until the mechanism is documented and reviewable. If the control only exists as policy language, require stronger contractual or technical evidence before relying on it.
Practitioner takeaway: The core test is whether the vendor can prove the boundary without relying on trust in a person, because discretionary controls fail precisely when the organisation needs them to be predictable.
Related resources from NHI Mgmt Group
- What are the signs that AI platform access controls are too broad for tenant separation?
- What are the signs that AI access controls are too permissive in a GenAI programme?
- What are the signs that AI agent security controls are too weak?
- What are the signs that AI security controls are too dependent on frontier model defaults?