EVIDENCE TRAIL
Least-privilege tool scoping
Verbatim excerpts from the upstream sources cited on the mitigation page, with what each source does and does not prove. The canonical control statement comes from NIST SP 800-53 AC-6; the agentic-AI application of it — per-tool least-privilege profiles with action, resource, and parameter scope dimensions — is named explicitly in OWASP Top 10 Agentic 2026 §ASI02 and OWASP AI Exchange #LEAST MODEL PRIVILEGE.
Last cross-checked against upstream sources: · 9 sources
References
Each entry shows what the source supports and what it does not prove.
NIST SP 800-53 Rev 5 — AC-6 Least Privilege
AC-6 — control statement (OSCAL prose field, ac-6_smt). Supplemental guidance adds: "Organizations employ least privilege for specific duties and systems. The principle of least privilege is also applied to system processes, ensuring that the processes have access to systems and operate at privilege levels no higher than necessary to accomplish organizational missions or business functions."
"Employ the principle of least privilege, allowing only authorized accesses for users (or processes acting on behalf of users) that are necessary to accomplish assigned organizational tasks."
Supports: Canonical control-library statement of least privilege. The "processes acting on behalf of users" framing directly maps to agents acting on behalf of humans — the same privilege-scoping obligation applies.
Does not prove: Does not address agentic AI, tool catalogs, OAuth scopes, or per-tool permission granularity. Generic information-system control; the agentic-AI application layer (action / resource / parameter scope triples) is Helmwart's extension.
OWASP Top 10 for Agentic Applications 2026
§ASI02 Tool Misuse and Exploitation — Prevention and Mitigation Guidelines, Mitigation 1
"Least Agency and Least Privilege for Tools. Define per-tool least-privilege profiles (scopes, maximum rate, and egress allowlists) and restrict agentic tool functionality and each tool's permissions and data scope to those profiles – e.g., read-only queries for databases, no send/delete rights for email summarizers, and minimal CRUD operations when exposing APIs. Where possible, express these profiles as IAM or authorization policy stanzas attached to each tool, rather than relying on ad-hoc conventions."
Supports: Verbatim statement of per-tool least-privilege scoping as the primary mitigation for Tool Misuse. Introduces the term "per-tool least-privilege profile" and explicitly names action scope (read-only vs send/delete), parameter scope (minimal CRUD), and the recommendation to express profiles as IAM policy stanzas — matching all three scope dimensions in the Helmwart control.
Does not prove: Does not address OAuth scope grammar (RFC 6749) or cloud-provider condition keys. Resource scope (tenant-scoped ARNs, per-user records) is implied but not spelled out.
OWASP Top 10 for Agentic Applications 2026
§ASI02 Tool Misuse and Exploitation — Common Examples of the Vulnerability, item 2
"Over-scoped tool access: Salesforce tool can get any record even though only the Opportunity object is required by the agent."
Supports: Canonical upstream illustration of the over-broad resource-scope failure this control prevents. The "get any record vs only the Opportunity object" example directly illustrates the resource-scope dimension.
Does not prove: Single illustrative example, not a general description of the control. Does not quantify blast radius or describe enforcement mechanisms.
OWASP Top 10 for Agentic Applications 2026
§ASI03 Identity and Privilege Abuse — Prevention and Mitigation Guidelines, Mitigation 1
"Enforce Task-Scoped, Time-Bound Permissions: Issue short-lived, narrowly scoped tokens per task and cap rights with permission boundaries - using per-agent identities and short-lived credentials (e.g., mTLS certificates or scoped tokens) - to limit blast radius, block delegated-abuse and maintenance-window attacks, and mitigate un-scoped inheritance, orphaned privileges, and reflection-loop elevation."
Supports: Establishes "narrowly scoped tokens per task" as the identity-level counterpart to tool-level scope restriction. Confirms "blast radius" as the framing for why narrow scope matters, and names un-scoped inheritance as the failure mode this control prevents.
Does not prove: ASI03's primary concern is privilege escalation via identity/delegation chains, not tool catalog breadth. Scope narrowness here is a token property, not a tool-catalog property — adjacent rationale, not identical control.
OWASP Agentic AI — Threats & Mitigations v1.1
§Tool, Execution and Supply Chain-Based Threats — Tool Misuse (T02) — Mitigation guidance paragraph
"To mitigate this, it is essential to properly scope agent entitlements by applying the principle of least privileges when operating on behalf of users, and validate whether users submitting the prompts have proper authorization to perform the requested actions. This is essential to prevent hijacking control via prompt injections and Identity spoofing and impersonation."
Supports: Names "properly scope agent entitlements by applying the principle of least privileges" as the direct T02 mitigation — the closest upstream wording match to Helmwart's control title. Also links scoping explicitly to prompt-injection resistance.
Does not prove: Guidance is written at the principle level, not the implementation level. Does not specify OAuth scopes, IAM policy triples, or parameter-level constraints.
OWASP Agentic AI — Threats & Mitigations v1.1
§T16 Insecure Inter-Agent Protocol Abuse — Scenario 3
"Scenario 3: Tool Misuse via Descriptive Exploitation – An attacker embeds misleading or overly broad tool descriptions in a shared tool registry. During agent collaboration, another agent accepts and calls the tool under false assumptions, unintentionally leaking sensitive data or triggering privileged API calls."
Supports: Demonstrates that scope inferred from a tool's self-description rather than enforced at the call boundary is a distinct attack surface. Confirms that tool-scope enforcement must be independent of the tool description — the same point made in the Helmwart MDX "fourth scope surface" discussion.
Does not prove: T16 is primarily about protocol abuse and inter-agent trust, not scoping misconfiguration per se. Scope independence is one implication of the scenario, not the main stated mitigation.
OWASP Agentic AI — Threats & Mitigations v1.1, Playbook 3
Playbook 3: Securing AI Tool Execution & Preventing Unauthorized Actions Across Supply Chains — Step 1 Restrict AI Tool Invocation, Execution and apply Supply Chain safeguards (Proactive), first bullet
"Implement strict tool access control policies and limit which tools agents can execute."
Supports: Verbatim upstream statement that tool access controls are the first proactive step in securing AI tool execution — corroborates m-tool-scope as the primary proactive control in its family.
Does not prove: One-line actionable item without elaboration on scope dimensions or policy enforcement mechanisms. Not specific to OAuth, IAM, or OPA patterns.
OAuth 2.0 — RFC 6749 §3.3 Access Token Scope
RFC 6749 §3.3 — "Access Token Scope", normative prose
"The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. In turn, the authorization server uses the "scope" response parameter to inform the client of the scope of the access token issued. The value of the scope parameter is expressed as a list of space-delimited, case-sensitive strings. The strings are defined by the authorization server."
Supports: Defines the canonical scope grammar (space-delimited strings, server-defined vocabulary) that the Helmwart control directs teams to use for identity-provider–level scope. Establishes that scope is a first-class token property, not an ad-hoc convention.
Does not prove: RFC 6749 is a general OAuth 2.0 specification. It does not address AI agents, tool catalogs, or the mapping of agent task roles to scope strings. The specific per-tool scope vocabulary is system-defined.
OWASP AI Exchange — #LEAST MODEL PRIVILEGE
OWASP AI Exchange §1 General Controls — #LEAST MODEL PRIVILEGE — definition
"Least model privilege: Minimize what a model can do (trigger actions or access data), to prevent harm in case the model is manipulated, or makes a mistake by itself."
Supports: Names "least model privilege" as a stand-alone AI control in the OWASP AI Exchange catalogue. Frames both action scope ("trigger actions") and data scope ("access data") as the two dimensions to minimize — matching Helmwart's action-scope and resource-scope dimensions. Also states: "Avoid implementing authorization in Generative AI instructions, as these are vulnerable to hallucination and manipulation" — the same rationale as Helmwart's MDX warning about description-inferred scope.
Does not prove: The AI Exchange entry is at the principle level. It does not describe implementation layers (OAuth, IAM triples, policy engines) and the word "scope" does not appear. The control name "least model privilege" differs from Helmwart's "least-privilege tool scoping" — the AI Exchange entry is broader (covers data access, not only tool actions).