---
title: 'Agent-Permissions.json: Agent Governance'
url: https://www.emergentmind.com/topics/agent-permissions-json
type: topic
---

# Agent-Permissions.json: Agent Governance

`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 [2601.02371] [2606.03024] [2603.17170] [2603.20953].

## 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 [2601.02371] [2604.02544] [2603.17170] [2606.03518].

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 [2604.02544] [2601.02371].

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 | [2601.02371], [2604.02544] |
| Runtime agent policies | Tool calls, file/network access, approvals, audit | [2603.20953], [2607.01510] |
| Skill/task manifests | Skill context/action capabilities, task-scoped operations | [2606.03024], [2603.17170], [2510.26212] |
| Delegation/identity manifests | Agent identity, PoP keys, chains of delegation, scopes | [2509.13597], [2606.03518] |

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` [2606.03024].

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 $eval(\sigma)=v$ together with structural agreement between the symbolic expression and the slice expectation [2603.17170].

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:
$$
I_{agent} = H(canon(prompt\_template)\,\|\,canon(prompt\_meta)\,\|\,canon(tools)\,\|\,canon(config)\,\|\,s).
$$
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 [2509.13597].

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 $\Delta_a^s$, deontic constraints $D_a^s$, and a mechanism $M_s$. The distinction matters because “there exists a permitted action that admits $\varphi$,” “there exists a permitted action that ensures $\varphi$,” “every $\varphi$-ensuring action is permitted,” and “every $\varphi$-admitting action is permitted” are pairwise non-interdefinable in general multiagent systems [2404.17053].

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 [2603.20953]. Agentic JWT introduces analogous identity-binding fields through `agent_checksum`, `registration_id`, `version`, `cnf.jkt`, allowed scopes, workflows, and delegation rules [2509.13597].

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 [2606.03024].

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 [2603.17170].

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 [2607.01510]. 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 [2511.17959].

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 [2601.02371] [2604.02544].

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 $R_{item}$, $R_{perm}$, and $R_{cond}$ [1804.06044]. 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 [2606.03024].

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
$$
authorize(\mathbf{T}, \mathbf{P}, \boldsymbol{\Pi}) \rightarrow (\mathbf{D}, \mathbf{L}),
$$
and each decision produces a cryptographically signed audit record linked into a SHA-256 hash chain [2603.20953].

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 [2603.17170].

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 [2509.13597].

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 [2603.20933].

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 [2601.02371].

## 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 [2606.03024].

In coding-agent environments, file-level least privilege becomes the primary concern. AuthBench models a policy as three whitelists, $\pi=(\pi_r,\pi_w,\pi_x)$, 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 [2605.14859].

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 [2601.02371] [2604.02544].

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 $Permit(a,s,p,o,c)$ with deny-by-default semantics and no role inheritance [2605.05269].

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 [1012.0759].

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 [2607.01510]. 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 [2510.26212].

## 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 $P=85.6\%$, $R=97.1\%$, and $F1=91.0\%$, 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 [2606.03024].

OAP reports a measured median authorization latency of 53 ms across $N=1{,}000$ 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 [2603.20953].

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 \$0.002 to \$0.038 across the evaluated LLMs [2603.17170].

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 [2603.22853].

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 [2605.14859].

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 [2607.01510]. 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 [2511.17959].

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 [2601.02371]. 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.

Source: https://www.emergentmind.com/topics/agent-permissions-json