TwinEthosRequest access

Recommended guardrail

Scope every agent's tools and credentials to least privilege

Publish a declared scope per agent: which tools, which APIs, which data, which credentials, and which operations are destructive. Grant the minimum the task needs, make irreversible operations (delete, transfer, deploy, send externally) opt-in per grant, issue short-lived task-scoped credentials, and forbid the agent from using any credential it discovers rather than receives. Detect agents configured with broad or wildcard tool access, standing admin credentials, or destructive operations enabled by default.

TwinEthos recommendation — not law

This is TwinEthos's opinion of what a responsible AI integration does anyway. It is never a legal or standards requirement; where binding law applies, the law governs.

The recommended-guardrail rule files are open under CC BY 4.0; attribution and scope are in the terms.

Informational data, not legal advice. Summaries are TwinEthos's own words and rules have not been reviewed by a lawyer: check the official text before relying on any of it. A guard addresses an item; adding it is not a statement that your code meets any law.

Evidence grade

Standards consensus (2)

2 standards and frameworks · 2 graded incidents.

TwinEthos recommendation, not law. Where binding law applies, the law governs. No binding law in the corpus requires this control yet. 2 standards and frameworks recommend it (FINRA GenAI/Agentic Guidance, NIST AML Taxonomy (AI 100-2e2025) — Agentic). 2 graded incidents cited.

Standards and frameworks

Family “An AI agent's authority, reach, inputs, and components are not bounded and accountable”: binding law on related controls is in force in no jurisdiction. Context only: it does not change this guardrail's grade.

Graded incidents

  • Gemini accessed real third-party systems during an evaluation (2026-05; confirmed) CNN Business · evidence grade: press of record
  • Coding agent deleted a production database during a code freeze (2025-07; confirmed) The Register · evidence grade: press of record

The guard to add

Declare each agent's allowed tools and credentials explicitly, grant only what its task needs, and keep destructive operations off unless a grant names them.

A per-agent scope declaration that the runtime reads lists the tools, APIs, data, and credentials the agent gets and marks which operations are destructive; the agent is built from that list rather than ALL_TOOLS, a wildcard allowed_tools, or an unrestricted ShellTool / PythonREPLTool. Destructive or irreversible tools (delete, transfer, deploy, external send) are registered only when the grant opts in. The agent's cloud or database identity is a narrow role (named actions on named resources, a read-only DB user), issued as short-lived credentials, and the agent has no path to pick up credentials from repositories, env files, or content it reads.

Example (LangGraph create_react_agent), before:

agent = create_react_agent(llm, tools=[ShellTool(), PythonREPLTool(), *crm_tools])

After:

scope = load_agent_scope('support-agent')   # declared tools; destructive ops opt-in
tools = [t for t in crm_tools if t.name in scope.allowed_tools]   # e.g. lookup_order, read_ticket
if scope.grants('issue_refund'):
    tools.append(issue_refund)
agent = create_react_agent(llm, tools=tools)

Control: Agent tools and credentials not scoped to least privilege. Engineering guidance, not legal advice.

Why

The same permission model that lets an agent be hijacked is the one that lets it cause harm by accident. Least privilege is the single control that bounds both. It is universal security practice, but no AI law in the corpus requires it of agents.

Class: agent security · set: agent containment · maturity: reviewed · confidence: high · id guardrail.agent-least-privilege-tool-scope