Agent-Permissions.json: Agent Governance

Updated 4 July 2026

agent-permissions.json is a machine-readable permission manifest that defines permissions for autonomous agents through least privilege, deny-by-default, and scoped delegation.
It comprises a family of schemas—from site manifests to runtime and task-specific policies—each enabling auditability and automated decision-making.
The file integrates formal authorization semantics with runtime mediation, significantly reducing attack success rates while maintaining task utility.

agent-permissions.json is a machine-readable permission manifest proposed as a governance layer for autonomous agents. In the literature, it is not a single standardized artifact but a family of closely related policy documents: a robots.txt-style site manifest for web agents, a skill manifest that binds declared intent to runtime behavior, a task-scoped authorization record for concrete tool calls, a signed “passport plus policy mapping” for pre-action authorization, and a runtime policy surface for user-involved permission assistants. Across these variants, the common objective is to express least privilege, deny-by-default behavior, scoped delegation, runtime mediation, and auditable decisions in a form that agent runtimes can parse and enforce automatically (Marro et al., 7 Dec 2025, Pan et al., 2 Jun 2026, Sharma et al., 17 Mar 2026, Uchibeke, 21 Mar 2026).

1. Conceptual emergence and scope

The emergence of agent-permissions.json reflects a shift from crawler-era governance to agent-era governance. Traditional mechanisms such as robots.txt regulate URL fetching, but modern agents navigate interfaces, extract structured information, submit forms, invoke tools, manipulate files, and coordinate with other agents. Multiple papers therefore recast permissions as an explicit, machine-readable contract between an agent and its execution environment, rather than as an implicit consequence of API keys, OAuth scopes, or trust in the application bundle (Marro et al., 7 Dec 2025, Borysenko, 2 Apr 2026, Sharma et al., 17 Mar 2026, Ibrahim et al., 2 Jun 2026).

A closely related distinction appears in documentation and web-agent settings. One line of work places agent-permissions.json alongside LLMs.txt, AGENTS.md, and skill.md, but assigns it a distinct role: LLMs.txt guides discovery, skill.md summarizes capabilities, AGENTS.md provides repository-scoped guidance, and agent-permissions.json governs what automated interactions are allowed and how they should be carried out responsibly (Borysenko, 2 Apr 2026, Marro et al., 7 Dec 2025).

A useful way to organize the literature is by the protected surface each manifest governs.

Family	Protected surface	Representative papers
Site/web manifests	HTTP interactions, DOM actions, preferred endpoints	(Marro et al., 7 Dec 2025, Borysenko, 2 Apr 2026)
Runtime agent policies	Tool calls, file/network access, approvals, audit	(Uchibeke, 21 Mar 2026, Brigham et al., 1 Jul 2026)
Skill/task manifests	Skill context/action capabilities, task-scoped operations	(Pan et al., 2 Jun 2026, Sharma et al., 17 Mar 2026, Cai et al., 30 Oct 2025)
Delegation/identity manifests	Agent identity, PoP keys, chains of delegation, scopes	(Goswami, 16 Sep 2025, Ibrahim et al., 2 Jun 2026)

This diversity indicates that agent-permissions.json is best understood as a policy idiom rather than a single schema. The idiom is stable—JSON policy, explicit scope, runtime checks, auditability—but the object model depends on whether the system is governing a website, a skill marketplace, a coding agent, a knowledge graph, or a user-facing permission assistant.

2. Formal authorization semantics

The strongest formulations in the literature replace coarse operator- or principal-scoped authorization with semantics tied to what an agent may actually influence or do. SkillGuard formalizes this as a dual-plane model. A skill declares permissions for context influence in $M_c$ and action side effects in $M_a$ ; at runtime, requested operations $R_c$ and $R_a$ are compliant only when $R_c \subseteq M_c$ and $R_a \subseteq M_a$ . Enforcement is defined by a function $E(R,M)$ that returns allow when $R \subseteq M$ , returns a user prompt when a matching confirm entry exists and constraints are satisfied, and otherwise returns deny (Pan et al., 2 Jun 2026).

PAuth pushes the same idea further by making authorization task-scoped rather than operator-scoped. A concrete call $c$ is permitted only when it matches a server-derived slice of the natural-language task and is validated by envelopes carrying cryptographically attested provenance:

$Permit(c, Slice_S(T), Env) \Leftrightarrow Consistent(c, Slice_S(T), Env).$

The consistency check is split into operand correctness and provenance correctness, and envelope validation requires concrete-symbolic equality $M_a$ 0 together with structural agreement between the symbolic expression and the slice expectation (Sharma et al., 17 Mar 2026).

Delegation-centered systems express the same shift in relational form. In Agentic JWT, an API call is bound to the acting agent’s identity, the originating user intent, a workflow step, a delegation chain, and a proof-of-possession key. The identity digest is derived from canonicalized prompt, tools, configuration, and a salt:

$M_a$ 1

This is then embedded into a token carrying intent, agent_proof, and cnf.jkt, so that a verifier can reject scope inflation, replay, impersonation, or workflow-step bypass (Goswami, 16 Sep 2025).

A more general logical account appears in the modal treatment of agentive permissions. That work distinguishes four forms: weak permission to admit, weak permission to ensure, strong permission to ensure, and strong permission to admit. Their semantics are given over transition systems with action spaces $M_a$ 2, deontic constraints $M_a$ 3, and a mechanism $M_a$ 4. The distinction matters because “there exists a permitted action that admits $M_a$ 5,” “there exists a permitted action that ensures $M_a$ 6,” “every $M_a$ 7-ensuring action is permitted,” and “every $M_a$ 8-admitting action is permitted” are pairwise non-interdefinable in general multiagent systems (Shi, 2024).

The broader implication is that agent-permissions.json has become a carrier for multiple formal views of permission: capability inclusion, task consistency, deontic admissibility, contractual delegation, and runtime confirmation. These views are compatible in spirit but not interchangeable.

3. Schema families and recurring fields

Although there is no canonical schema, several recurrent design patterns appear. The first is identity and provenance. OAP-style manifests require fields such as issuer, subject, status, assurance_level, valid_from, valid_until, canonical_hash, registry_sig, and registry_key_id, treating the file as a signed passport bound to a registry authority and an authorization service key (Uchibeke, 21 Mar 2026). Agentic JWT introduces analogous identity-binding fields through agent_checksum, registration_id, version, cnf.jkt, allowed scopes, workflows, and delegation rules (Goswami, 16 Sep 2025).

A second pattern is explicit permission partitioning. SkillGuard requires metadata, policy_mode, deny_by_default, and permissions, with permissions further partitioned into context, actions, and data_access. Context permissions include capabilities such as LOAD_CONTEXT, RESTRICT_POLICY, and model configuration mutations; action permissions include canonical capabilities such as READ_FILE, WRITE_FILE, FETCH_WEB, POST_WEB, and INVOKE_TOOL; data_access covers categories such as PII, SECRETS, FINANCIAL, HEALTH, SOURCE_CODE, and RESEARCH_DATA, each with allow, confirm, or deny, hazard levels, and constraints (Pan et al., 2 Jun 2026).

A third pattern is task- or slice-level specification. PAuth’s proposed schema centers on task_id, natural_language_task, allowed_services, allowed_operations, provenance_policy, and warnings. Each allowed operation can carry constant or symbolic arguments, guards, let_defs, cross-service dependencies, time windows, budgets, recipients, rate limits, and envelope requirements. In this design, the manifest is a compiled representation of slice rules rather than a simple access-control list (Sharma et al., 17 Mar 2026).

A fourth pattern is adaptive decision support. Janus-style manifests add assistant_mode, global_defaults, thresholds, rules, escalation_paths, fatigue controls, batching controls, and logging preferences. Here the file governs not only whether access is allowed, but how the system should combine deterministic rules, AI risk scoring, human confirmation, and policy updates (Brigham et al., 1 Jul 2026). A related line of work proposes thresholds, calibration, risk costs, context descriptors, personalization state, and fallback behavior so that an ML permission assistant can auto-approve or auto-deny only in high-confidence regions (Wu et al., 22 Nov 2025).

Site-scoped manifests are intentionally smaller. The web-agent permission-manifest work specifies four top-level fields—metadata, resource_rules, action_guidelines, and api—while the documentation-portal work emphasizes rate limits, human-in-the-loop requirements, and preferred endpoints in a lightweight, robots.txt-style file (Marro et al., 7 Dec 2025, Borysenko, 2 Apr 2026).

An older antecedent comes from JSON-based ABAC with string-based resource naming. That work is not agent-specific, but it already treats JSON as the carrier for customized permissions, conditions, comparisons, aggregation, and conflict resolution over encoded resource names such as $M_a$ 9, $R_c$ 0, and $R_c$ 1 (Liu et al., 2018). This suggests that contemporary agent manifests inherit part of their shape from pre-agent JSON authorization systems, while extending them with runtime mediation and agent-specific provenance.

4. Enforcement and runtime mediation

The file becomes operational only when embedded in a mediation pipeline. Several papers therefore treat agent-permissions.json as an input to a policy enforcement point rather than as documentation. In SkillGuard, enforcement occurs at lifecycle hooks such as SessionStart and PreToolUse. Each context mutation or tool invocation is mapped to a canonical capability, matched against policy entries under deny-by-default semantics, and either allowed, denied, or routed through user-mediated authorization. Every decision is appended to an audit trail with session identifier, hook event, mapped capability, inputs, policy source, and decision rationale (Pan et al., 2 Jun 2026).

OAP makes this pre-action placement explicit. Its before_tool_call interceptor synchronously blocks execution until policy evaluation returns ALLOW, DENY, or ESCALATE. Matching order is deterministic: status, capability scope, policy pack presence, assurance level, deny rules, approval workflow, then allow. The authorization function is written as

$R_c$ 2

and each decision produces a cryptographically signed audit record linked into a SHA-256 hash chain (Uchibeke, 21 Mar 2026).

PAuth enforces even tighter coupling between task semantics and runtime behavior. Servers independently derive slices, compile them into enforcer rules, and then validate every concrete call against guards, symbolic argument expressions, and attached envelopes. Off-slice calls are denied with precise, task-scoped warnings rather than with coarse scope failures. This is enforced server-side, not just in the client runtime (Sharma et al., 17 Mar 2026).

Agentic JWT inserts a shim into the client path. The shim self-verifies, computes the agent checksum, tracks workflow state, derives step-scoped Ed25519 proof-of-possession keys, mints intent tokens, and signs HTTP requests. Resource servers then verify the JWT, the request signature, the delegation chain, the workflow step, the audience binding, and replay protection. The manifest in this setting determines which agents, scopes, workflows, and delegation edges are valid (Goswami, 16 Sep 2025).

AC4A illustrates the same principle in API and browser contexts. For APIs, the runtime computes the needed permissions for an endpoint call and checks them via resource_difference. For browser agents, it maps selectors to resource value specifications and actions, then hides unauthorized DOM elements before the agent can observe or operate on them. This makes the manifest part of the observable environment, not merely a post hoc audit artifact (Sharma et al., 21 Mar 2026).

In web-agent governance, enforcement occurs at the browser layer rather than the tool layer. Before performing read_content, follow_link, click_element, submit_form, or play_media, an agent checks whether the manifest’s resource_rules authorize the verb on the target selector and whether modifiers such as rate_limit or human_in_the_loop apply. action_guidelines are treated differently: they are planner-facing normative constraints rather than mechanically enforced browser rules (Marro et al., 7 Dec 2025).

5. Domain-specific instantiations

The literature now spans several distinct application domains. In skill ecosystems, agent-permissions.json governs both context influence and side effects for reusable agent skills. SkillGuard treats a skill as a permission-bearing executable artifact, with canonical capabilities over storage, repositories, network, execution, hardware, system configuration, secrets, agent ecosystem resources, and policy mutations (Pan et al., 2 Jun 2026).

In coding-agent environments, file-level least privilege becomes the primary concern. AuthBench models a policy as three whitelists, $R_c$ 3, over read, write, and execute permissions for terminal tasks. The proposed Sufficiency-Tightness Decomposition first generates a coverage-oriented policy via forward simulation, then prunes entries lacking grounding or overlapping sensitive surfaces. In this setting, agent-permissions.json is effectively a minimal filesystem-and-executable boundary for a single task (Yan et al., 14 May 2026).

In web and documentation ecosystems, the manifest is site-scoped. The web-agent papers place it at /.well-known/agent-permissions.json or expose it through a page-level <link rel="agent-permissions">. Here it regulates DOM verbs, rate limits, human approval for sensitive actions, and preferred APIs such as OpenAPI, MCP, or A2A endpoints. Documentation-portal deployments additionally use it as part of an analytics-aware stack that steers agents toward token-efficient, canonical endpoints (Marro et al., 7 Dec 2025, Borysenko, 2 Apr 2026).

In 6G knowledge-base agents, the file serializes a hybrid of roles and first-order predicates for zero-trust triple-level access control. Policies bind agents to explicit flat roles, triple scopes over subject–predicate–object patterns, DSL or AST predicates over context and provenance, wildcard protection against variable predicates, and obligations such as logging and provenance checks. The permission function is defined over triples as $R_c$ 4 with deny-by-default semantics and no role inheritance (Abdelrazek et al., 6 May 2026).

In secure data sharing for untrusted clouds, the manifest becomes a signed grant token. It binds a subject, a grantor, a dossier resource, permitted actions, scope, time bounds, delegation depth, epoch-bound key material, and signature. The cloud-side synchronizer stores ciphertexts and sealed keys but never plaintext, so agent-permissions.json acts as the policy wrapper around cryptographic grant-and-revoke workflows (Damiani et al., 2010).

In user-facing agent systems, the file also becomes a human-involvement policy. Janus uses it to configure permission assistants such as risk_assessment, risk_assessment_autonomous, auto_approve, user_confirmation, constitution, and policy_suggestion, together with fatigue controls, batching, escalation, and logging (Brigham et al., 1 Jul 2026). AgentSentry uses a task-scoped variant to encode app packages, activities, UI selectors, tool denylists, invariants such as no_write_email, and revocation conditions so that injected instructions cannot escape the current task boundary (Cai et al., 30 Oct 2025).

6. Empirical findings, limitations, and open disputes

The empirical case for agent-permissions.json is strongest when the file is treated as an enforceable runtime artifact rather than as advisory metadata. SkillGuard evaluated 315 real-world skills and SkillInject. Its permission taxonomy covered 99.76% of observed protected objects, automated manifest generation reached $R_c$ 5, $R_c$ 6, and $R_c$ 7, and attack success decreased from 32.37% to 23.02% for contextual injections and from 25.56% to 16.67% for obvious injections while benign task utility remained essentially intact (Pan et al., 2 Jun 2026).

OAP reports a measured median authorization latency of 53 ms across $R_c$ 8 decisions. In a live adversarial testbed with 4,437 authorization decisions across 1,151 sessions and a \$5,000 bounty, social engineering succeeded 74.6% of the time under a permissive policy, whereas a restrictive OAP policy yielded a 0% success rate across 879 attempts (Uchibeke, 21 Mar 2026).

PAuth’s evaluation shows a different trade-off: all 100 benign tasks completed successfully without requiring additional permissions, while 634 forced prompt-injection scenarios across Banking, Slack, Workspace, Travel, and Shopping produced zero false positives and zero false negatives. The same work reports per-task token costs ranging from \$R_c$90.038 across the evaluated LLMs (Sharma et al., 17 Mar 2026).

Agent Audit demonstrates the value of scanning manifests as deployment artifacts. On 22 samples with 42 annotated vulnerabilities, it detected 40 vulnerabilities with 6 false positives, corresponding to 95.24% recall, 86.96% precision, and approximately 0.909 F1. It specifically targets over-broad filesystem access, unverified server sources, sensitive environment variable exposure, missing sandboxing, missing authentication, and related MCP-configuration risks (Zhang et al., 24 Mar 2026).

AuthBench shows that direct policy generation remains difficult even for frontier models. The paper argues that the bottleneck is permission-boundary inference itself, not merely conservative-versus-permissive calibration. Its Sufficiency-Tightness Decomposition improved sensitive-task success by up to 15.8% on tightness-biased models and reduced attack success across all evaluated models; for permissive models, it sharply lowered Sensitive-File Exposure Rate and Attack Success Rate, although sometimes with a Task Success Rate cost (Yan et al., 14 May 2026).

User-involved permission management complicates the picture further. Janus reports that user input is critical, AI augmentation can reduce cognitive load, permission fatigue is real, and no single permission-assistant design performs optimally across all contexts (Brigham et al., 1 Jul 2026). A related ML-based permission-assistant study reports 85.1% overall prediction accuracy, 94.4% accuracy for high-confidence predictions, 66.9% accuracy with no user history, and a 10.8 percentage-point gain after only 1–4 user-labeled samples (Wu et al., 22 Nov 2025).

Two open disputes remain visible across the literature. First, standardization is unresolved: the site-level manifest papers explicitly describe a lightweight, robots.txt-style file but do not define a universal schema, while runtime systems adopt far richer policy objects (Marro et al., 7 Dec 2025). Second, compliance can be advisory or enforceable depending on the deployment. A web portal can publish agent-permissions.json, but only runtime interception, server-side task checking, cryptographic binding, or deny-by-default mediators convert the manifest from guidance into a security boundary.