Dynamic Capability Scoping for Enterprise AI Agents: A Synthetic Dataset and Three-Source Permission Architecture

What it is

A workshop paper (AIWILD @ ICML 2026, by independent researcher Halil Burak Noyan) arguing that AI-agent capability scoping should be treated as prevention before detection: a credential absent from an agent's context cannot be misused no matter how well the agent reasons around monitors. The summary covers the dataset and the three-source idea; what it omits is how the three sources actually combine, what threat they target, and the deployment modes — the parts an engineer would act on.

How it works

The three sources combine by intersection — a permission is granted only if Source 1 permits it, Source 2 predicts it, and Source 3 does not prohibit it:

• Source 1 (role ceiling): deterministic department→max-permission lookup, no runtime inference. Sets a hard upper bound. Extends to non-human agents via service-level IAM principals (AWS principal model) rather than department roles.
• Source 2 (task classifier): a fine-tuned multi-label classifier predicts required permissions from the user's task description, independent of the agent — the agent never declares or influences its own permissions. The orchestrator applies asymmetric confidence thresholds by risk: high-risk permissions (database_read, email_send_external) need high confidence; low-risk (confluence_read) granted at lower confidence to avoid breaking common tasks. This layer is the most precise but the most vulnerable — prompt injection or document pollution in the task text can inflate its output.
• Source 3 (combination prohibitions): deterministic filter targeting Willison's lethal trifecta (private-data access + untrusted content + external communication). It makes the trifecta structurally impossible by banning co-occurrence, e.g. in TechCorp policy database_read cannot coexist with email_send_external or http_request; Source 3 strips the external-comms permission. Rules can be hand-authored or auto-derived via Policy-as-Prompt so updating the policy updates the prohibitions.

The paper's worked case: a vuln-management agent with model-weight access and HTTP is a direct weight-exfiltration path that bypasses Sources 1–2 via a side task — Source 3 encodes "no internet for agents touching model weights."

flowchart LR
  T[Task description] --> S2[Source 2: classifier]
  R[Role/principal] --> S1[Source 1: ceiling]
  S1 --> X{Intersect}
  S2 --> X
  X --> S3{Source 3: combo prohibited?}
  S3 -->|yes| D[Strip external-comms]
  S3 -->|no| G[Grant]
  D --> G

What to do

Two deployment modes, and the observe-only one is the actionable near-term option:

• Enforcing: orchestrator deploys only predicted credentials, blocks tool calls outside the set.
• Observe-only: deploys the full role ceiling but still computes task/policy outputs and emits a structured event whenever the agent invokes a tool the full system would have denied — mirrors SELinux permissive mode. This yields a behavioral misalignment signal without exposing production to undershoot (broken tasks).

Dataset, TechCorp policy, generation/labeling scripts, and validation outputs are released under GPL-3.0 at https://github.com/0xballistics/mostargate. Use the dataset as training input for the Source 2 classifier.

Caveats

The authors are explicit that this paper only releases the dataset and shows synthetic generation can drive policy refinement (46→3 ceiling violations) — it does not evaluate architectural performance; the per-source ablation is future work. The threat model trusts the classifier, credential-deployment service, and orchestrator, and the paper notes trusting an LLM classifier is a stronger assumption than trusting the deterministic components. Fully-autonomous service agents and gradual scope creep within a task are explicitly out of scope.