Agent-market authorization is not a credential problem, because credentials answer a subject question while live policy answers a state question: whether this agent can perform this action under a policy root that may have moved since the last task.
A verifiable credential works cleanly when the verifier needs a durable attribute, because the claim travels with the subject and the verifier decides whether the issuer is acceptable for that context [1], but the same shape becomes unstable once permission has to track revocation, expiry, resource scope, and marketplace-specific policy state.
When an agent presents a broad credential, a marketplace asking whether it can perform trading_analysis::technical::crypto may also learn permission breadth, operator structure, model lineage, issuer path, and adjacent scopes that have nothing to do with the requested task, so capability becomes public metadata rather than private operating context. Making the credential narrower does not remove the problem as much as relocate it, because every policy change then needs new issuance, every revocation needs reliable indexing, and every verifier needs to agree which credential version still maps to the current boundary, which is the contrast in the diagram below: one path leaks outward from the agent while the other keeps the verifier focused on a single authorization claim.
Scoped Authorization Proofs treat authorization as an inclusion statement rather than an identity statement. SAP proves that a claimed action exists inside a committed policy set without revealing the set itself, so the public verifier sees policy_root and action_hash, while the raw action type, scope, expiry, salt, sibling path, leaf index, and unrelated leaves stay private [2].
Project Emtun uses (action_type, scope, expiry, agent_salt) as the leaf preimage and commits the policy set through a Poseidon2 Merkle tree. A Noir circuit then needs to enforce only the load-bearing constraints: (a) the private tuple hashes into the public action_hash, and (b) that leaf sits under the public policy_root through the private Merkle path [3]. The verifier learns that the action is authorized under the committed root, not what else the agent can do, which is the same authorization boundary explored in the longer SAP construction note.
The Merkle path is the point where the disclosure boundary becomes visible: sibling hashes and indices are witness material, while root and action hash are enough for the verifier to check the authorization claim.
ERC-8004 gives agents a useful identity boundary by making registration and discovery legible onchain, but identity still answers who or what is being referenced rather than whether one requested action is currently permitted [4]. EAS-style attestations can anchor claims and commitments, yet the same separation applies: an attestation can point to a policy root, a registry can identify the agent, and a proof can bind one action to that root without forcing any single layer to pretend it proves everything [5].
Settlement also stays outside the SAP statement. A requester may accept a committed result hash and release escrow, but the proof has only shown permission, not execution correctness, so correctness still belongs to verifiable compute, optimistic dispute, TEE evidence, validation markets, or another primitive with its own failure model. The authorization proof becomes weaker if it quietly absorbs claims about model behavior, tool use, hidden workflow fidelity, or downstream performance.
Identity, authorization, settlement, and execution correctness touch the same transaction, but their trust boundaries terminate in different places.
The useful part of SAP is not that it makes agent authorization feel more complete. Its value is the opposite: it keeps the claim small enough to be true. Credentials terminate trust at an issuer statement about an agent, while SAP terminates trust at inclusion under a live policy root, and that difference changes where disclosure happens, where revocation has force, and where the verifier is allowed to stop asking for private context.
Agent markets will need identity, reputation, settlement, and execution guarantees, but those objects should not be compressed into one credential-shaped claim. A verifier that only needs one permission check should receive one permission proof, while the rest of the agent's capability graph remains private unless the task genuinely requires it.