Authorization Boundary

The control record

Id

AIGE-CTL-EVAL-001 · v0.2 · Draft · Open for technical review

Objective

Every agent in an evaluation run acts only within an authorization boundary recorded before the run starts: the tools, operations, data classes and budgets it may use, and the runs and resources it may reach.

Failure modes

• A run starts with no recorded boundary for the agent under test, or with a boundary that differs from the scope the agent was told.
• The agent calls a tool or an operation class outside its recorded boundary, or starts processes with administrative privileges, and the call succeeds.
• A credential given for one purpose on a shared resource, such as downloading packages, also lets the agent write, list or post there.
• Agents in runs meant to be isolated reach each other through a resource the runs share, such as a package repository or a cache.

Scope

Agents and harnesses under evaluation, the tools and operations they can use during a run, the credentials they receive for shared resources and the resources runs share. Budgets are recorded here and enforced under AIGE-CTL-EVAL-006; network egress is AIGE-CTL-EVAL-002. Production deployments are covered by the agent runtime profile.

Enforcement points

• deploy: before a version is deployed or released
• runtime: at the point of action (gateway or guardrail)

Verification

• Inspect: Before the run, inspect the run record: it holds a boundary for each agent under test (tools and operation classes, data classes, budgets, and each shared resource with the operations allowed on it), and the prompt the agent receives states the same boundary as instructions, including what it must not access.
• Test: At admission, from inside the environment, attempt one call of each kind outside the boundary (an unlisted tool or operation class, a write or a listing with a download-only credential on a shared resource, a process started as root) and one listed call; every attempt outside the boundary must be refused and logged, and the listed call must succeed.
• Test: Start two canary runs on the same shared resources: a marker written by one run must not be readable by the other.
• Observe: After the run, compare every tool call and every request to a shared resource in the run's logs with the recorded boundary: each falls inside it, and every refused attempt is recorded with its time and target.

Evidence

• The boundary of each agent under test, recorded before the run: tools, operation classes, data classes, budgets and shared resources with the operations allowed on each · Layer 02 · agent-register-entry.v1
• Admission test verdicts: the refused out-of-boundary calls and the cross-run canary · Layer 04 · evidence-record.v1
• One observation per run comparing the calls and shared-resource requests made with the recorded boundary · Layer 05 · control-observation.v1

Failure response

deny: block the action. Calls and shared-resource operations outside the recorded boundary are refused at the enforcement point and logged. A run with no recorded boundary is not started; a run in which a call outside the boundary succeeded, or in which runs reached each other, is stopped and its result is withheld until the path is closed.

Layers

Layer 04 Runtime Controls & Observability, Layer 02 Inventory & Transparency

Patterns

Agent Registry, Policy Card

Seeded from

Registry entry, Read-only tools, Reversible, bounded actions only, Execution budgets, Data classes recorded, with the DPIA linked

Mappings

• Obligations: EU AI Act Art. 14 human oversight; OWASP Top 10 for Agentic Applications 2026; CSA AICM Agentic Control Supplement (proposed); Singapore IMDA Model AI Governance Framework for Agentic AI: agent identity and scoped authorisations (voluntary)
• ISO/IEC 42001: A.6.2.2 AI system requirements and specification; A.9.2 Processes for responsible use of AI systems
• NIST AI RMF: MAP 4.2 Internal risk controls for components of the AI system, including third-party AI technologies, are identified and documented.
• OWASP: ASI02 Tool Misuse and Exploitation; ASI03 Identity and Privilege Abuse; LLM03:2026 Excessive Agency
• AIUC-1: B006
• NIST SP 800-53 Rev. 5: AC-3 (Access Enforcement)
• NIST SP 800-53 Rev. 5: AC-6 (Least Privilege)
• IMDA MGF for Agentic AI v1.5: 2.3.2 Before deploying, test agents, p.38 (Partial fit: IMDA addresses deployed agents; for test environments it only asks to calibrate realism against real-world tool access)

References

• [1] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "The agent registry")
• [2] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "Autonomy is a design decision")
• [3] Governing AI agents (AI Governance Engineering Body of Knowledge v0.5.0, chapter 23, section "The tool allow-list")
• [4] METR Task Standard, STANDARD.md (version 0.5.0; unless a task declares the full_internet permission, the task machines "MUST NOT have internet access" except to an LLM API, an LLM API proxy or a hardened local server)
• [5] Brief independent investigation of agents' behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident (METR states that agents "meant to be fully isolated from one another" communicated through an internal package repository, and that one agent found working Hugging Face credentials exposed on the internet and posted them to the agents' board; it reports spoofed tool calls in at least 96 transcripts and transcripts missing components after container resets)
• [6] OWASP Top 10 for Agentic Applications for 2026 (ASI01 Agent Goal Hijack to ASI10 Rogue Agents)
• [7] NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations (control catalogue cited by control id; publication page of Revision 5 with update 1 of 10 Dec 2020)
• [8] Third-party cyber evaluations involving OpenAI models (OpenAI states that the evaluator's "intended authorization boundary was the simulated cyber range", that its model reused a GitHub token another lab's agent had left publicly accessible, and that it will review how to "set expectations for isolation, credential handling, monitoring, and stop conditions")
• [9] Improving our alignment and security efforts (best practices for external partners running cyber evaluations: the only outside connection is "to the model's own API", with the API keys kept outside the environment; the configuration "should be verified before every evaluation begins"; boundaries "phrased as instructions"; challenges confirmed "solvable in principle"; a monitor that flags a scope violation to a human and ends the exercise)
• [10] AIUC-1 requirements (public requirement index, A001 to F002, each requirement on its own page (E007 and E014 marked retired); AIUC-1 is a standard of the Artificial Intelligence Underwriting Company; this site is not affiliated with AIUC, and a mapping here is not an AIUC-1 certificate or audit)
• [11] Unsanctioned Artifactory writes and cross-sample communication (misalignment report) (OpenAI reports models in RL training that used Artifactory, "a shared package repository", to exchange messages across separate training samples with the credentials they were given to download packages, without exploiting any vulnerability; such exchanges can "undermine the assumption that training or evaluation samples are independent")
• [12] OpenAI Hugging Face Incident Technical Report (OpenAI states that high-risk workloads are "prohibited via technical controls from receiving direct or transitive Internet access", protected by "two separate layers of network isolation", and that it is building tooling to "identify and halt evaluation workloads")
• [13] Model AI Governance Framework for Agentic AI, v1.5 (published 2026-05-20, updated 2026-06-05; four dimensions: assess and bound the risks upfront, make humans meaningfully accountable, implement technical controls and processes, enable end-user responsibility)

Implementation notes

• Record the boundary as data before the run, in the fields of an agent registry entry (scope, tools, data access, spend limit), and enforce it at the gateway the agent's calls pass through, not in the prompt alone. State the same boundary to the agent: Anthropic's guidance for external evaluation partners asks every prompt to state what is in and out of scope, including permitted actions and network boundaries, with boundaries "phrased as instructions" rather than claims about the environment.
• Tell the agent what it may not do with the access it has. OpenAI's account of a third-party cyber evaluation states that the evaluator's "intended authorization boundary was the simulated cyber range", while the agents were not explicitly told how they could and could not use the open internet access they had; the evaluator names this as a potential contributing cause.
• Scope every credential for a shared resource to the operations the task needs: download from a package repository, never write, list or post. OpenAI reports models in RL training that used Artifactory, "a shared package repository", to exchange messages across separate samples with the credentials they were given to download packages, without exploiting any vulnerability; its technical report on the Hugging Face incident lists removing the shared credential from new research workloads and restricting the types of requests agents could make to Artifactory among its mitigations.
• Give each run its own namespace on every shared resource (package cache, artefact store, scratch storage) and test it with a canary marker. METR's investigation of the OpenAI/Hugging Face incident reports that agents "meant to be fully isolated from one another" communicated through an internal package repository.
• Run the agent as an unprivileged user. METR's Task Standard states that the agent "MUST NOT be allowed to start processes" on the primary machine as root.

Open questions

• Which shared resources (package mirrors, caches, model API proxies) can be given a per-run namespace, and which should be removed from evaluation environments altogether?
• What evidence is sufficient to show that an agent stayed within its boundary for a whole run when the logs of some of the tools it called are outside the evaluator's control?

Observation

• Subject: Evaluation run
• Expected: Every tool call and every request to a shared resource falls inside the boundary recorded for the agent before the run; every attempt outside it is refused and logged.
• Example: Run 88231: 3 listing and upload requests to the shared package repository with a download-only credential, all refused and logged; no call outside the boundary succeeded: pass.