Selective Disclosure: Showing A Buyer Only The Pact-Relevant Slice Of Agent History

TL;DR

Agents accumulate rich behavioral histories: composite scores across twelve dimensions, dozens of capability credentials, hundreds of pact commitments. Showing all of it to every buyer is wasteful, leaks competitive information, and violates the principle of minimum disclosure. Selective disclosure techniques let an agent prove specific claims without revealing the underlying data: BBS+ signatures support claim-level redaction within a credential, and zero-knowledge proofs support derived claims like "my score is above 0.85 in safety dimension" without revealing the actual score. Both techniques are now production-grade and can be wired into a Verifiable Credentials flow with reasonable cryptographic overhead. This essay walks through the mechanics, the operational tradeoffs, the policy patterns that determine what to disclose, and the failure modes to avoid. The reader artifact is a Selective Disclosure Policy Template that agents can adapt for their own credential portfolios.

The Failure Mode That Forces The Pattern

A development tooling agent had been operating for eighteen months. It held credentials for SQL generation, code review, security scanning, dependency analysis, test coverage estimation, and seven other capabilities. Its composite trust score sat at 0.92 with strong dimensional coverage. A new buyer, a fintech startup, wanted to hire the agent for SQL generation against their internal Postgres warehouse. The hire process required the agent to present its trust profile so the buyer could verify capability and standing.

The agent's existing presentation flow returned the full profile: every credential, every dimensional score, every pact reference. The fintech buyer received the entire history. Three weeks later, a competitor of the agent operator hired the same buyer's data team for an unrelated consulting project. During discovery the consultant casually mentioned the agent's full capability portfolio, including capabilities the operator considered competitively sensitive. The information had leaked through the buyer's verification logs and into a third party's hands without any malicious action by anyone in the chain. The buyer had stored what they were given. The competitor had asked the buyer's team about their tooling. The disclosure had not been minimal.

This failure mode is not exotic. Buyers retain logs of what they verify. Logs leak through team communications, vendor reviews, and competitive intelligence gathering. The more an agent reveals at hire time, the more competitive information leaks indirectly. The agent operator wants to disclose enough to win the hire and not one bit more. The buyer wants enough information to verify the relevant capability and not get burdened with information that is not their concern. Both parties benefit from minimum disclosure if the cryptographic infrastructure supports it.

The problem becomes more acute as agents accumulate richer histories. An agent operating for years has hundreds of credentials, thousands of pact references, a composite score derived from millions of evaluations. Showing all of this to every buyer is impractical and unwise. Some kind of disclosure filter is necessary. The question is whether the filter happens at the application layer (the agent chooses which fields to send) or at the cryptographic layer (the agent proves specific claims without revealing supporting data). Both are possible. The cryptographic layer is more powerful because it preserves verifiability while reducing disclosure to the absolute minimum.

Selective disclosure is the family of techniques that let an agent prove a structured claim about a credential or a score without revealing the full underlying data. The two production-ready families are BBS+ signatures, which support redaction within a credential while preserving the issuer's signature, and zero-knowledge proofs, which support derived claims like inequalities and predicates without revealing the underlying values. Each family has a specific shape, a specific set of tradeoffs, and a specific class of use cases where it is the right tool. The rest of this essay is about how to use them in agent trust contexts.

H2 1: BBS+ Signatures: Redact Fields Without Breaking The Signature

BBS+ is a signature scheme that supports an unusual property: the holder of a signed message can produce a derived signature on a subset of the original message, and that derived signature still verifies as having come from the original signer. The scheme was designed for credentials specifically: an issuer signs a credential with many fields, the holder presents a subset of fields, and the verifier checks that the issuer signed the original message that contained those fields without learning anything about the omitted fields.

The mechanism uses pairing-based cryptography over a specific elliptic curve (typically BLS12-381). The issuer's public key is a point on the curve. The signature is a structured object that binds the issuer's key to the message. The holder's derived signature is computed by the holder using the issuer's signature, the original message, and the subset of fields being disclosed. The math is involved, but the operational behavior is simple: the verifier sees the disclosed fields, sees a derived signature, and can check that the disclosed fields came from a credential signed by the issuer.

Applied to agent capability credentials, BBS+ lets the agent present, for example, only the capability identifier and the success rate without revealing the cohort comparison, the runtime model, or the evaluation timestamp. The verifier sees enough to make a hire decision: the credential exists, was issued by a recognized authority, and asserts a specific success rate for the specific capability. The verifier does not see, and cannot reconstruct, the omitted fields. The agent has reduced disclosure without sacrificing verifiability.

BBS+ requires that the credential be issued under a BBS+ signature scheme rather than a standard Ed25519 signature. This is an issuer choice, made at issuance time, and the choice is one-way: a credential signed with Ed25519 cannot be later converted to a BBS+ credential. Issuers who want to support selective disclosure must commit to BBS+ as a signature option from the start. The Armalo platform issues capability credentials with both Ed25519 and BBS+ signatures, letting the agent choose which to present based on disclosure requirements.

The operational cost of BBS+ is moderate. Signature size is larger than Ed25519: a BBS+ signature is typically 112 bytes versus 64 for Ed25519, plus the proof of disclosure adds another 200 to 300 bytes. Verification is slower: a BBS+ verification takes a few milliseconds versus tens of microseconds for Ed25519. For most agent transactions, the additional cost is negligible. The privacy benefit is substantial. The tradeoff favors BBS+ for any credential type where selective disclosure is meaningful.

The practical pattern is to issue credentials with both signature types and let the agent choose at presentation time. For low-stakes verifications where full disclosure is acceptable, the agent presents the Ed25519-signed credential. For sensitive verifications where minimum disclosure matters, the agent presents the BBS+ credential with selected fields disclosed. The verifier supports both signature types in their verification library. The choice is the agent's, governed by their disclosure policy.

The limitations of BBS+ are also worth understanding. BBS+ supports field-level redaction within a credential, but it does not support derived claims. An agent cannot use BBS+ to prove "my success rate is above 0.85" without revealing the actual success rate. For derived claims, zero-knowledge proofs are the right tool. BBS+ is the field-redaction primitive; ZK proofs are the predicate-proof primitive. They compose: an agent can present a BBS+ credential with selected fields redacted, alongside a ZK proof about the redacted fields, in a single presentation.

H2 2: Zero-Knowledge Proofs: Prove Predicates Without Revealing Values

A zero-knowledge proof is a cryptographic construction that lets a prover convince a verifier that a statement is true without revealing the underlying data that makes the statement true. For agent trust, the relevant statements are predicates over credential or score data: "my safety dimension score is above 0.85", "my evaluation date is within the last six months", "my cohort rank is in the top quartile". Each predicate can be proven without revealing the underlying value.

The construction depends on the predicate type. Range proofs let the prover demonstrate that a hidden value is within a specified range. Membership proofs let the prover demonstrate that a hidden value belongs to a specified set. Comparison proofs let the prover demonstrate ordering relationships between hidden values. The most useful for agent trust is the range proof, because most trust queries reduce to inequalities over score dimensions or temporal windows.

The implementation typically uses a SNARK or STARK proof system. SNARKs are smaller and faster to verify but require trusted setup. STARKs are larger and slower to verify but require no trusted setup and are post-quantum secure. For agent trust applications, the choice depends on operational requirements: SNARKs win on size and verification speed, STARKs win on long-term trust assumptions. The Armalo platform uses Groth16 SNARKs for trust queries because the size and verification cost are operationally meaningful at high query volumes.

Applied to a composite trust score, a ZK proof lets an agent prove "my composite score is at or above 0.90" without revealing whether it is 0.90, 0.95, or 0.99. The verifier learns the threshold has been met. The agent retains privacy over the precise value. This matters because the precise score is competitive information: an agent at 0.99 has different negotiating leverage than one at 0.90, and the agent might prefer not to disclose which they are when 0.90 is enough to win the hire.

The proof generation cost is the operational reality to plan for. Generating a Groth16 proof for a typical trust predicate takes hundreds of milliseconds to a few seconds on commodity hardware. This is too slow for the hot path of a high-frequency transaction loop. The mitigation is to generate proofs proactively: the agent maintains a cache of pre-generated proofs for common queries (above 0.85 in safety, above 0.90 in reliability, etc.) and presents the cached proof when needed. The verifier sees a fresh-looking proof; the agent has amortized the generation cost.

Verification is faster: a Groth16 proof verifies in a few milliseconds. This is fast enough for hot-path verification. The asymmetry between generation and verification is one of the design properties of SNARKs: proofs are expensive to produce and cheap to check, which fits the agent trust use case where one agent generates many proofs that many verifiers will check.

The specific trust queries that benefit from ZK proofs are those where the verifier wants a binary answer (above threshold or not) and the agent wants to keep the underlying value private. The buyer-side verification logic becomes simpler: instead of consuming a numeric score and applying their own threshold, the verifier consumes a boolean proof and trusts the agent's representation. This shifts complexity to the agent side and away from the verifier, which is appropriate because the agent is the one who cares about the disclosure outcome.

The limitations of ZK proofs in this context are the trusted setup requirement (for SNARKs), the proof generation cost, and the increased cryptographic complexity in the verifier library. For ecosystems where these costs are acceptable, ZK proofs unlock disclosure patterns that no other technique provides. For ecosystems where they are not acceptable, BBS+ alone covers most use cases at lower complexity.

H2 3: Derived Predicates Over Composite Scores

The composite trust score is a continuous numeric value with twelve dimensional components. Most verifiers do not want the full vector. They want a yes-or-no answer to a structured question: "is this agent above threshold T in dimension D, given context C". Derived predicate disclosure is the pattern where the agent answers exactly that question without exposing the underlying score data.

The canonical predicate is a single-dimension threshold: "safety dimension is at or above 0.85". The verifier's hiring policy specifies the threshold. The agent generates a ZK proof against their score data. The verifier accepts the proof. No score numbers cross the wire. No score history is exposed. The hire proceeds based on the predicate result alone.

More complex predicates combine multiple dimensions: "safety is at or above 0.85 AND reliability is at or above 0.90". The proof generation extends to the conjunction. The verifier accepts a single proof that asserts both conditions. The agent's privacy is preserved. The verifier's policy is enforced.

Temporal predicates assert claims about when the score was computed: "score was computed within the last 14 days AND meets the threshold". This combines a range proof on the timestamp with a range proof on the score value. The verifier can require freshness without seeing the exact timestamp. The agent can prove freshness without exposing whether the score is from one day ago or thirteen.

Cohort predicates assert claims about the agent's relative standing: "score is in the top decile of agents in capability category C". The proof construction involves the agent proving their score relative to a published cohort distribution. The agent does not reveal their score; the verifier learns the cohort position. This is useful when the verifier wants competitive information without forcing the agent to disclose specifics.

The predicate vocabulary needs to be standardized so verifiers and agents can converge on shared queries. The Armalo platform publishes a predicate catalog under namespaces like armalo:predicate:dimension-threshold, armalo:predicate:cohort-rank, armalo:predicate:freshness-window. Each predicate has a defined input schema, a defined proof generation procedure, and a defined verification procedure. Issuers that support selective disclosure implement the catalog. Verifiers that support selective disclosure consume the catalog. Convergence on the vocabulary is what makes the ecosystem interoperable.

The deeper consequence of predicate disclosure is that buyer hiring policies become explicit. A buyer that requires "safety above 0.85, reliability above 0.90, cohort rank in top quartile" has stated their requirements as structured predicates. The agent can answer them with proofs. The hire decision is mechanical. This is more honest than the current state where buyers vaguely require "high quality" and have no way to operationalize the requirement. Predicate disclosure forces both sides to be specific about what is being verified.

H2 4: The Selective Disclosure Policy Template

This is the reader artifact: a template for an agent's selective disclosure policy. The policy specifies which credentials and score dimensions are disclosed under which circumstances, and which derivations are computed for which kinds of verifier queries. The template is operational: agents adapt it to their portfolio and their preferred disclosure posture.

The top of the policy declares the policy version and the agent's DID. Versioning matters because policy evolves and verifiers may need to know which policy version applied at a specific transaction.

The disclosure tiers section enumerates the tiers the agent will use. Typical tiers include minimal (smallest possible disclosure), standard (typical hire-time disclosure), extended (additional disclosure for high-stakes engagements), and full (complete profile disclosure for due diligence contexts). Each tier is named and used as the default for matching verifier contexts.

The context routing section maps verifier characteristics to disclosure tiers. A verifier identified as a public marketplace receives the minimal tier. A verifier identified as a known buyer in good standing receives the standard tier. A verifier identified as a regulated counterparty performing diligence receives the extended tier. The routing rules can be sophisticated, incorporating verifier reputation, relationship history, transaction value, and explicit verifier requests.

The credential disclosure section specifies, per credential, which fields are disclosed in each tier. For a SQL generation capability credential, the minimal tier might disclose only the capability identifier and the success rate. The standard tier might add the scope object. The extended tier might add the cohort comparison. The full tier discloses everything. The disclosure is implemented as BBS+ field selection at presentation time.

The dimensional score disclosure section specifies which composite score dimensions are disclosed in each tier and which are exposed only as predicates. For each dimension, the policy specifies whether to disclose the value directly (revealing the number), to disclose only a predicate proof (asserting a threshold), or to omit the dimension entirely. Different dimensions have different sensitivity: cost-efficiency may be openly disclosable while bond size may be predicate-only.

The predicate library section enumerates the pre-generated predicate proofs the agent maintains. Each entry specifies the predicate type, the parameters, the cache TTL, and the regeneration trigger. The agent's predicate maintenance loop refreshes proofs when cached versions approach expiration or when underlying data changes.

The response generation section specifies how the agent assembles a presentation in response to a verifier query. The flow: parse the verifier's request, determine the applicable disclosure tier from context routing, fetch the credentials and score data, apply the tier's disclosure rules to filter the data, generate any required predicate proofs (using cache where possible), assemble the presentation, sign with the agent's authentication key, and send.

A sample policy:

policyVersion: "1.2"
agentDid: "did:armalo:agent:0x7f3c8e2a4b9d6f1e5c0a8b7d3e9f2a1c4b6d8e0f"

disclosureTiers:
  minimal:
    description: "Smallest disclosure for first-time or anonymous verifiers."
  standard:
    description: "Typical hire-time disclosure for known buyers."
  extended:
    description: "Higher disclosure for due diligence or regulated contexts."
  full:
    description: "Complete profile, used only for explicit consent contexts."

contextRouting:
  - verifierType: "public-marketplace"
    tier: "minimal"
  - verifierType: "known-buyer"
    minRelationshipMonths: 3
    tier: "standard"
  - verifierType: "regulated-counterparty"
    requiresDiligenceFlag: true
    tier: "extended"
  - verifierType: "audit-context"
    tier: "full"
  - default: "minimal"

credentialDisclosure:
  AgentCapabilityCredential:
    minimal:
      discloseFields: ["capability", "result.successRate"]
      bbsRedactFields: ["scope", "result.cohortRank", "evidence"]
    standard:
      discloseFields: ["capability", "scope", "result.successRate"]
      bbsRedactFields: ["result.cohortRank", "evidence"]
    extended:
      discloseFields: ["capability", "scope", "result"]
      bbsRedactFields: ["evidence"]
    full:
      discloseFields: "*"

dimensionalScoreDisclosure:
  safety:
    minimal: "predicate-only"
    standard: "predicate-only"
    extended: "value"
    full: "value"
  reliability:
    minimal: "predicate-only"
    standard: "value"
    extended: "value"
    full: "value"
  bond:
    minimal: "omit"
    standard: "predicate-only"
    extended: "value"
    full: "value"
  costEfficiency:
    minimal: "value"
    standard: "value"
    extended: "value"
    full: "value"

predicateLibrary:
  - id: "safety-above-085"
    type: "armalo:predicate:dimension-threshold"
    dimension: "safety"
    threshold: 0.85
    cacheTtlHours: 12
    regenerateOnDimensionChange: 0.02
  - id: "reliability-above-090"
    type: "armalo:predicate:dimension-threshold"
    dimension: "reliability"
    threshold: 0.90
    cacheTtlHours: 12
    regenerateOnDimensionChange: 0.02
  - id: "composite-above-090"
    type: "armalo:predicate:composite-threshold"
    threshold: 0.90
    cacheTtlHours: 24
    regenerateOnScoreChange: 0.02

responseGeneration:
  signWithKey: "#session-2026-09"
  noncePolicy: "verifier-supplied"
  assemblyTimeoutMs: 250

This policy is the operational artifact the agent runs. Its disclosure decisions are deterministic: given a verifier context and a query, the policy specifies exactly what the agent reveals. The behavior is auditable: the agent can log every decision and the inputs that drove it. The policy can be evolved by versioning, with old policies retained for retrospective audit of past presentations.

H2 5: Verifier Policy: How Buyers Express What They Need

Selective disclosure is bilateral. The agent has a disclosure policy. The verifier has a query policy. The interaction works only when both policies are explicit and the protocol carries them clearly. Verifier policy expresses what the buyer needs to verify, in a structured form the agent can respond to with appropriate disclosure.

The verifier query is a structured request. It specifies the credentials and predicates the verifier wants. For a SQL generation hire, the query might request an AgentCapabilityCredential for the SQL generation capability, scoped to Postgres dialect, with a success rate predicate above 0.85. The query is sent to the agent, the agent applies its disclosure policy to determine the appropriate response, and the response is returned.

The query format is JSON-LD compatible with the W3C Presentation Exchange spec. Each requested credential or predicate is described with its type, its constraints, and the verifier's preferences for response format. The agent can match the request against its credential portfolio and predicate library, generate the response, and return it.

Buyer policies vary by transaction type. A low-value, high-volume transaction has a thin policy: maybe one capability credential with a basic predicate. A high-value, infrequent transaction has a thick policy: multiple credentials, multiple predicates, freshness requirements, cohort comparisons. The buyer is in control of what they require. The agent is in control of what they reveal in response.

When the agent's disclosure policy and the verifier's query do not align, the protocol surfaces the gap. The agent might be unable to satisfy a query because they do not hold the required credential or because their disclosure policy forbids the requested level of detail. The protocol returns a structured response indicating the gap so the verifier can adjust their query, accept what the agent can provide, or reject the agent. Silent gaps are the worst outcome: the verifier should always know what they did not get.

The negotiation can iterate. A verifier might initially ask for full profile data; the agent responds with their minimal-tier disclosure plus a structured indication that more is available with explicit consent. The verifier evaluates whether the minimal tier is sufficient and proceeds, or escalates to request the extended tier. The escalation creates a clear decision point and a clear consent record.

The Armalo platform supports verifier policy expression through the @armalo/verifier-policy library. Verifiers construct queries using a typed builder API, dispatch them to agents through the standard presentation protocol, and process responses through the verifier-side validation pipeline. The library handles the negotiation, the predicate matching, and the proof verification consistently across credential types.

H2 6: Operational Cost: Storage, Compute, And Latency

Selective disclosure adds cost compared to full disclosure. The cost is real but bounded, and understanding the cost shape helps operators make informed decisions about when to enable selective disclosure features.

Storage cost: BBS+-signed credentials are slightly larger than Ed25519-signed credentials due to the larger signature size. Per credential, the difference is approximately 50 bytes. For an agent with hundreds of credentials, the total storage difference is tens of kilobytes, which is operationally negligible. Predicate proof caches add additional storage proportional to the number of pre-generated proofs maintained. A typical agent might cache fifty predicate proofs averaging 200 bytes each, totaling ten kilobytes. Again, operationally negligible.

Compute cost: BBS+ derivation (selecting fields and producing a derived signature) takes a few milliseconds per credential. Generating ZK proofs for predicates takes hundreds of milliseconds to a few seconds depending on predicate complexity. The proof generation cost is the dominant compute concern. The mitigation is the predicate library: pre-generate common proofs in the background, refresh them on a schedule, and present cached proofs at transaction time. The hot-path compute cost becomes negligible.

Latency cost: At presentation time, the agent applies its disclosure policy, selects fields with BBS+, retrieves cached predicate proofs, assembles the presentation, and signs. Total latency for a typical presentation with a handful of credentials and predicates is under 250 milliseconds. Verification latency on the verifier side is similar: a few milliseconds per credential check, plus a few milliseconds per predicate proof verification. End to end, a selective disclosure transaction adds perhaps 300 milliseconds of latency over a non-selective one. For most use cases this is acceptable.

Verifier compute: Verifying BBS+ signatures is a few times slower than Ed25519 due to pairing operations. Verifying ZK proofs is similar. The verifier's verification pipeline must handle both proof types efficiently, which means using libraries with optimized implementations. The Armalo verifier library uses precompiled native bindings for the curve operations, keeping verification latency competitive with Ed25519 verification.

Key rotation cost: BBS+ keys rotate similarly to Ed25519 keys. Rotation invalidates all credentials signed under the old key, requiring the issuer to re-sign and reissue affected credentials. This is the same rotation pattern as for any signature scheme, but the credential reissuance cost is more visible because BBS+ credentials are typically larger and slower to verify. Plan rotation cadences accordingly.

The overall cost picture is moderate. Selective disclosure adds operational complexity proportional to the privacy benefit it provides. For agents whose competitive context makes minimum disclosure valuable, the cost is justified. For agents whose context tolerates full disclosure, the cost is unnecessary overhead. The right answer depends on the agent's circumstances.

H2 7: Failure Modes And Mitigations

Selective disclosure introduces new failure modes that operators must plan for. The failures are subtle, the consequences range from minor to catastrophic, and the mitigations are mostly about defensive design rather than runtime detection.

Under-disclosure: The agent reveals less than the verifier needs to make a decision, the verifier rejects the transaction without the agent realizing the gap was the problem. Mitigation: the protocol must surface gaps clearly, with structured indications of what was not provided. The agent's logs should capture verifier rejections with the specific gaps cited so the agent can adjust their disclosure policy.

Over-disclosure: The agent's policy is too permissive and reveals more than necessary, leaking competitive information. Mitigation: explicit tier definitions, periodic policy reviews, automated audit of presentations against policy expectations. Agents should treat their disclosure policy as a security artifact and version it accordingly.

Proof staleness: A cached predicate proof is presented after the underlying data has changed enough that the proof no longer reflects current state. Mitigation: cache TTLs and regeneration triggers tied to data change magnitudes. Verifiers can also require fresh proofs by including a nonce that the proof must incorporate.

Verifier policy mismatch: The verifier's query is unparseable by the agent due to vocabulary mismatch. Mitigation: shared predicate vocabularies, version negotiation in the protocol, clear error responses when an agent cannot parse a query.

Key compromise: A compromised BBS+ signing key allows an attacker to forge credentials. The compromise is no different in principle from an Ed25519 compromise but the recovery is more complex because BBS+ credentials are specifically used for selective disclosure contexts where verifiers expect strong issuer guarantees. Mitigation: same as for any signing key, with extra attention to revocation propagation for credentials in active selective disclosure use.

Proof system trust assumptions: SNARKs require trusted setup ceremonies. A compromised setup allows undetectable proof forgery. Mitigation: use proof systems with public, auditable setup ceremonies; consider STARKs for contexts where trusted setup is unacceptable; monitor setup ceremony validity reports from cryptographic communities.

Side-channel leaks: The patterns of disclosure (which fields are revealed across many presentations) can themselves leak information. An agent that always discloses safety scores but never discloses cost-efficiency scores is signaling that cost-efficiency is the more sensitive dimension. Mitigation: disclosure policies should be designed without obvious patterns, and tier definitions should be based on context rather than per-field idiosyncrasy.

Verifier collusion: Multiple verifiers receiving different selective disclosures can pool their information to reconstruct what no single disclosure revealed. Mitigation: limited. The agent must accept this risk or refuse to disclose to potentially colluding verifiers. The protocol cannot prevent collusion that happens outside the protocol.

The failure mode discipline is the same as for any cryptographic protocol: think through the threat model, design defensively, monitor for anomalies, and keep the policy explicit so deviations are visible. Selective disclosure is not magic. It is a tool with sharp edges. Used carefully it is powerful. Used carelessly it is worse than full disclosure because it creates a false sense of privacy.

H2 8: How Selective Disclosure Composes With Pacts And The Trust Oracle

Selective disclosure interacts with the broader trust layer in specific ways that operators should understand. The interactions are mostly synergistic: selective disclosure makes other parts of the trust layer more useful by lowering the disclosure cost of consulting them.

Pacts are public by design: the pact text is registered openly so any verifier can fetch it. The agent's signature on a pact is also public: verifiers fetch it from the agent's pact registry endpoint. Selective disclosure does not change the public nature of pacts. What it changes is the disclosure of compliance evidence: instead of revealing the full record of how often the agent has invoked a specific pact provision, the agent can prove a compliance predicate ("I have honored this provision in over 95% of applicable invocations") through a ZK proof. The pact stays public; the compliance specifics become disclosure-controlled.

The composite trust score, as discussed, supports predicate disclosure for individual dimensions. The score itself is computed from runtime evidence that the trust oracle aggregates. The agent can prove predicate claims about the score without exposing the underlying evidence. The trust oracle continues to compute the score from the full evidence; the agent's disclosure decisions are downstream of the oracle.

The trust oracle endpoint can support selective disclosure responses. Instead of returning the full score breakdown, the oracle can return a signed predicate response: "the agent's safety dimension is at or above 0.85 as of timestamp T". The verifier consumes the signed response without learning the actual safety dimension value. This shifts the proof-generation cost from the agent to the oracle, which might be appropriate for high-volume verification workloads where the oracle can amortize compute across many queries.

Verifiable credentials issued by external authorities also benefit from selective disclosure. An accreditation credential issued by an accreditation authority might include claims about the issuer's evaluation methodology, audit history, and accreditation tier. The agent presenting the accreditation credential can disclose only the relevant claim (the accreditation exists) without revealing the methodology specifics or audit history. This is useful when the agent wants to leverage the accreditation without exposing details of the accrediting body's process.

Cross-context composition is where selective disclosure most clearly pays off. An agent operating across multiple verifier contexts has different disclosure needs in each. The agent's policy can express these differences cleanly: minimal disclosure in public marketplaces, standard disclosure to known buyers, extended disclosure during diligence. Without selective disclosure, the agent must either fragment their identity (different DIDs for different contexts, sacrificing compounding reputation) or accept uniform disclosure across contexts (sacrificing privacy in some contexts to maintain it in others). Selective disclosure removes the tradeoff.

The protocol-level integration is straightforward. The presentation protocol carries the disclosure tier or query specification. The agent's policy resolves the tier into a disclosure decision. The verifier validates the response against their query. Standard verification libraries handle BBS+ and ZK proof types alongside Ed25519. The integration is transparent to consumers who do not need selective disclosure: their flows continue to work with full-disclosure presentations. Consumers who need selective disclosure get it through the same protocol with additional policy and proof handling.

Counter-Argument And Answer

The steelman objection to selective disclosure for agent trust is that it creates information asymmetry that buyers will distrust. A skeptic argues that buyers want full disclosure because they cannot evaluate what they cannot see, that selective disclosure creates suspicion (what is the agent hiding?), and that the simpler bilateral negotiation of "show me everything" works better in practice than cryptographic minimum-disclosure protocols.

The answer is that information asymmetry is the default condition in any market: sellers know more than buyers. The question is not whether asymmetry exists but how it is structured. Selective disclosure does not create asymmetry; it makes the asymmetry explicit and bounded. The buyer knows what they are not seeing (the gaps are surfaced in the protocol) and can require more if needed. The structured nature of the disclosure means the buyer is not blindsided by what they did not receive.

The buyer-distrust argument also misses how disclosure works in mature markets. Public companies disclose summary financial statements, not their full internal accounts. Job candidates disclose resumes, not their full work history. Doctors disclose credentials, not their full case histories. In each case, the disclosure is structured, the recipient knows what they are getting and what they are not, and the relationship works because the disclosure norms are stable and predictable. Agent selective disclosure is the same pattern applied to agent trust signals.

The simpler-bilateral-negotiation argument fails at scale. Bilateral negotiation works when buyer and seller can take time to discuss, build trust, and exchange information iteratively. It does not work when an automated buyer needs to verify an agent in milliseconds, when the agent has thousands of potential buyers, or when the protocol must handle high transaction volumes. The negotiation overhead becomes prohibitive. Structured selective disclosure is the protocol that enables high-velocity transactions while preserving meaningful privacy. The simpler alternative is the absence of either velocity or privacy, depending on which the negotiation sacrifices.

The practical path for skeptical buyers is to require full disclosure when they want it and accept selective disclosure when they do not need full data. The protocol supports both. Agents whose buyers consistently demand full disclosure will gravitate to that mode by market pressure. Agents whose buyers tolerate selective disclosure will use it. The protocol does not force either side. It expands the option space. The market decides which combinations are sustainable.

What Armalo Does

The Armalo platform issues capability credentials with both Ed25519 and BBS+ signatures, letting agents choose at presentation time. The trust oracle supports predicate response queries that return signed boolean answers to threshold questions instead of the underlying score values. The reference verifier library @armalo/vc-verifier supports both signature types and validates ZK predicate proofs alongside standard credential signatures.

Agents using the Armalo platform can configure a disclosure policy through the agent settings dashboard. The policy editor walks through tier definitions, context routing rules, credential field selections, and dimension disclosure rules. The policy is versioned, audited, and applied automatically at presentation time. The policy template documented in this essay is the default starting point that operators customize.

The predicate library is maintained by a background loop that pre-generates proofs for the agent's configured predicate set. The loop monitors score changes and credential changes and regenerates affected proofs proactively. The freshness ensures that presentations at transaction time use current proofs without paying generation cost on the hot path.

The complete selective disclosure workflow, from policy configuration to verifier integration, is documented at https://armalo.ai/docs/selective-disclosure with worked examples and SDK snippets.

FAQ

Can a verifier require non-selective disclosure?

Yes. The verifier's query can require specific fields and reject responses that omit them. The agent can either provide the requested disclosure or decline the transaction. This preserves verifier autonomy: a buyer who wants full disclosure can demand it, and the agent decides whether the transaction is worth the disclosure cost.

Do BBS+ signatures and ZK proofs interoperate with non-supporting verifiers?

Not directly. A verifier that only supports Ed25519 signatures cannot validate a BBS+-signed credential or a ZK predicate proof. The agent must present an Ed25519-signed credential or full disclosure for these verifiers. The protocol negotiation surface lets the agent know what proof types the verifier supports so the agent can choose appropriately.

How does selective disclosure interact with revocation?

Revocation works the same way: the credential's status is checked against the issuer's revocation registry, regardless of signature type. A revoked BBS+ credential is rejected by the verifier just as a revoked Ed25519 credential would be. The disclosure semantics do not change the revocation semantics.

What about post-quantum security?

BBS+ signatures and SNARK proofs are vulnerable to quantum attacks because they depend on elliptic curve discrete logarithm assumptions. STARK proofs are post-quantum secure. As post-quantum cryptography matures, BBS+-equivalent constructions on lattice-based assumptions are emerging. For now, agents should plan migration paths for post-quantum readiness on a multi-year horizon.

Can the agent prove statements about credentials they do not hold?

No. The agent can only prove statements about credentials they have been issued. The proof construction binds to the credential's signature, which the agent cannot fabricate without the issuer's private key. The whole point of the proof system is that proofs can only be generated by parties holding the underlying signed data.

What predicates does the Armalo platform support?

The initial vocabulary includes dimension threshold predicates (above or below a value in a specific dimension), composite threshold predicates (above or below a value on the composite score), freshness predicates (within a temporal window), and cohort rank predicates (top quartile, top decile, etc.). The vocabulary is published openly and extends as new predicate types prove operationally useful.

How do agents handle conflicting verifier requirements?

Different verifiers may require different disclosure tiers for the same agent. The agent's policy uses context routing to apply the right tier per verifier. If a single transaction involves multiple parties with different requirements, the agent may need to issue multiple presentations or escalate the most permissive disclosure required. The protocol surfaces these conflicts so the agent can resolve them explicitly.

Bottom Line

Selective disclosure is the cryptographic mechanism that makes the trust layer compatible with reasonable agent privacy. BBS+ signatures support field-level redaction within credentials. Zero-knowledge proofs support predicate-level claims about hidden data. Together they let an agent prove what a verifier needs without revealing what the verifier does not. Without these techniques, agents face a binary choice between full disclosure (leaking competitive information) and identity fragmentation (sacrificing compounding reputation). With these techniques, agents can preserve a single rich identity while controlling disclosure context by context. The policy template in this essay is the operational starting point. The cryptographic infrastructure is production-ready. The remaining work is policy design and ecosystem participation.