Credential Presentation Minimisation Governance

2. Summary

Credential Presentation Minimisation Governance requires that identity verification in AI agent governance workflows reveals only the minimum attributes necessary for the specific control decision being made. When a governance system needs to verify that an approver holds a certain role, it should not also learn their date of birth, home address, or national identifier. When an agent needs to confirm that a requester is over 18, it should not receive the requester's exact age. This principle — drawn from privacy-by-design and data minimisation requirements — protects against attribute leakage, credential over-exposure, and the accumulation of unnecessary identity data in governance logs. In agent ecosystems where credentials may be verified thousands of times per day across multiple systems, each unnecessary attribute disclosure compounds the privacy risk and the attack surface.

3. Example

Scenario A — Over-Exposed Credentials in Agent Governance Logs: An AI agent governance platform requires administrators to authenticate with a corporate credential that contains: full name, employee ID, department, role, email address, phone number, date of birth, national insurance number, and home address. Every authentication event logs the full credential assertion. Over 18 months, the governance log accumulates 340,000 authentication events containing the personal data of 127 administrators. A breach of the governance log exposes the national insurance numbers and home addresses of all 127 individuals.

What went wrong: The credential contained far more attributes than the governance system needed. For each authentication, the system needed only: employee ID, role, and current proofing level. The additional attributes were transmitted, processed, and logged unnecessarily. The governance log became a high-value target because it contained sensitive personal data that had no governance purpose. Consequence: GDPR breach notification for 127 data subjects, ICO investigation for data minimisation violation, £680,000 in remediation costs, reputational damage to the governance programme.

Scenario B — Attribute Linkage Creates Tracking Risk: A customer-facing AI agent requires age verification before providing financial advice. The age verification credential issued by a third-party identity provider includes the customer's full name, date of birth, and a persistent unique identifier. The agent logs this credential for audit purposes. The same customer interacts with multiple agents across the organisation, each of which logs the full credential. An analyst correlating governance logs across agents can now track the customer's interactions across all systems using the persistent identifier — creating a surveillance capability that was never authorised.

What went wrong: The credential disclosed more than necessary (full name and DOB when only "over 18" was needed) and included a persistent identifier that enabled cross-system tracking. A minimal credential would disclose only a boolean "age ≥ 18" claim with a per-session pseudonymous identifier. Consequence: Privacy violation, potential GDPR Article 5(1)(c) breach for data minimisation, regulatory risk if the tracking capability is discovered.

Scenario C — Credential Replay Enabled by Over-Disclosure: A service authenticating to an agent governance system presents a SAML assertion containing 22 attributes including API keys, internal system identifiers, and database connection strings (inadvertently included in the assertion by a misconfigured identity provider). The governance system does not filter the assertion — it processes and logs all 22 attributes. A breach of the governance log exposes the API keys and connection strings, enabling lateral movement to 4 internal systems.

What went wrong: The credential contained operational secrets that should never have been in an identity assertion. The governance system did not validate or filter the assertion to retain only the minimum required attributes. The logging system preserved the full assertion. Consequence: Lateral movement to 4 systems, 2-week incident response, complete rotation of all exposed credentials, post-incident audit finding.

4. Requirement Statement

Scope: This dimension applies to every credential presentation in AI agent governance workflows — including authentication assertions, identity tokens, access tokens, attribute certificates, and verifiable credentials — whether presented by humans, services, or agents. The scope covers both the credential itself (what attributes it contains) and the governance system's processing of the credential (what attributes it consumes, logs, and stores). It applies to credentials issued internally (corporate identity providers) and externally (third-party identity providers, government digital identity schemes, decentralised identity wallets).

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

4.1. A conforming system MUST define and document the minimum set of identity attributes required for each category of agent governance decision, and MUST request only those attributes when verifying credentials.

4.2. A conforming system MUST NOT log, store, or transmit identity attributes that are not required for the specific governance decision, even if those attributes are present in the credential assertion.

4.3. A conforming system MUST filter incoming credential assertions to extract only the required attributes and discard the remainder before processing, logging, or forwarding.

4.4. A conforming system MUST use selective disclosure mechanisms where available (e.g., SD-JWT, BBS+ signatures, zero-knowledge proofs) to request only the required attributes from the credential holder, rather than receiving the full credential and filtering after receipt.

4.5. A conforming system MUST avoid using persistent unique identifiers across governance contexts unless cross-context linkage is a documented, justified, and audited requirement.

4.6. A conforming system SHOULD issue pairwise pseudonymous identifiers for each governance context, so that the same credential holder cannot be tracked across unrelated governance systems.

4.7. A conforming system SHOULD implement predicate proofs where possible (e.g., "age ≥ 18" rather than exact date of birth, "role = approver" rather than full role hierarchy) to disclose the minimum semantically necessary for the decision.

4.8. A conforming system SHOULD audit credential presentations periodically to verify that no unnecessary attributes are being requested, processed, or logged.

4.9. A conforming system MAY implement verifiable credentials with unlinkable presentation (e.g., BBS+ based credentials) to enable privacy-preserving authentication that prevents even the governance system from correlating presentations to specific credential issuance events.

5. Rationale

In AI agent governance ecosystems, credentials are verified frequently and across many systems. An agent governance platform may process thousands of authentication events per day. Each event that transmits unnecessary identity attributes creates cumulative risk: privacy risk (more personal data in more places), security risk (more sensitive attributes exposed to more systems), and compliance risk (more data to govern under data protection regulations).

The principle of data minimisation is well-established in privacy regulation (GDPR Article 5(1)(c), CCPA/CPRA purpose limitation) and security practice (need-to-know, least privilege). AG-284 applies this principle specifically to credential presentations in agent governance workflows, where the volume and frequency of authentication events amplify the consequences of over-disclosure.

The technical capability to implement credential minimisation has matured significantly. Selective Disclosure JWT (SD-JWT), BBS+ signature-based verifiable credentials, and zero-knowledge proof systems all enable the credential holder to prove specific attributes without revealing the full credential. For example, a verifiable credential containing name, DOB, address, and role can be presented with selective disclosure so that the verifier receives only the role claim. The remaining claims are cryptographically committed but not revealed.

Without credential minimisation, governance logs become accumulation points for sensitive personal data that has no governance purpose. These logs are high-value targets for attackers because they contain identity attributes that can be used for identity theft, social engineering, or lateral movement. AG-284 prevents this accumulation by requiring that governance systems request, process, and log only what they need.

6. Implementation Guidance

Credential presentation minimisation should be designed into the governance architecture from the outset, not retrofitted. The key design decisions are: what attributes does each governance decision require, and how can we present only those attributes?

Recommended patterns:

• Attribute requirement mapping. Create a formal mapping between each governance action type and the minimum attributes required to make the access/approval decision. Example mapping: mandate approval requires {employee_id, role, proofing_level}; configuration view requires {employee_id, department}; audit log access requires {employee_id, audit_role}; agent interaction requires {session_id, authorised_boolean}. This mapping is the foundation — without it, minimisation cannot be enforced.
• SD-JWT for internal credential flows. Use SD-JWT (Selective Disclosure JSON Web Token) for internal identity assertions. The identity provider issues a JWT with all attributes, but each attribute is individually disclosable. The governance system's authentication request specifies which attributes it needs, and the credential holder's client presents only those. The governance system can verify the signature over the disclosed attributes without seeing the undisclosed ones.
• BBS+ verifiable credentials for external/cross-boundary flows. For credentials crossing organisational boundaries (e.g., federated identity assertions from partner organisations, government-issued digital identity credentials), use BBS+ signature-based verifiable credentials that support unlinkable selective disclosure. The credential holder can prove specific attributes to different verifiers without the verifiers being able to correlate the presentations.
• Predicate proofs for threshold decisions. Where the governance decision is a threshold check (age ≥ 18, financial_limit ≥ £100,000, clearance_level ≥ SECRET), use zero-knowledge predicate proofs that prove the threshold is met without revealing the exact value. This is the strongest form of minimisation for threshold-based decisions.
• Governance log attribute filtering. Implement a logging filter at the governance system boundary that strips non-required attributes before writing to the audit log. The filter is configured from the attribute requirement mapping. Attributes that are not in the required set for the logged event type are replaced with a hash or omitted entirely.

Anti-patterns to avoid:

• Full-credential logging. Logging the complete SAML assertion, JWT, or credential presentation "for audit purposes." The audit purpose is served by logging the governance decision, the required attributes that informed it, and a reference to the credential — not the full credential with all attributes.
• Requesting all available attributes. Configuring the identity provider to include all user attributes in every assertion because "we might need them." This violates minimisation and creates unnecessary exposure. Request only what the attribute requirement mapping specifies.
• Persistent identifiers across contexts. Using a single employee ID or email address as the identifier across all governance systems when cross-system linkage is not required. This enables unauthorised tracking and correlation. Use pairwise pseudonymous identifiers where cross-system linkage is not needed.
• Client-side filtering only. Relying on the client or user agent to select which attributes to present, without the verifier enforcing the restriction. A compromised or misconfigured client may present all attributes. The governance system must enforce the filter server-side.
• Over-retention of presentation metadata. Retaining the full credential presentation history (which attributes were presented, when, to which system) when only the governance decision outcome needs to be retained. Presentation metadata can itself be sensitive.

Industry Considerations

Financial Services. MiFID II and FCA requirements for record-keeping can create tension with data minimisation — firms must retain sufficient records to reconstruct the decision-making process. AG-284's approach resolves this tension by requiring that only the minimum attributes necessary for the decision are retained, while ensuring those attributes are sufficient for regulatory reconstruction. The attribute requirement mapping provides the documented justification for what is retained and what is excluded.

Healthcare. HIPAA's Minimum Necessary Standard directly parallels AG-284. When AI agents process PHI under human governance, the governance credential should disclose only the attributes necessary for the governance decision (e.g., "role = attending_physician" rather than the physician's full personnel record). The governance log should not accumulate PHI from credential presentations.

Public Sector. eIDAS 2.0 digital identity wallets support selective disclosure by design. Public sector organisations adopting eIDAS wallets for agent governance authentication should leverage this capability to implement AG-284.

Maturity Model

Basic Implementation — The organisation has documented the minimum attributes required for each governance action type. The identity provider is configured to include only the required attributes in assertions for each relying party (per-service attribute release). Governance logs filter out non-required attributes before storage. Periodic manual audits verify that no unnecessary attributes are being logged. This meets minimum mandatory requirements but relies on correct configuration of the identity provider and manual audit.

Intermediate Implementation — Selective disclosure mechanisms (SD-JWT or equivalent) are used for internal credential flows. The governance system's authentication requests specify required attributes, and only those are disclosed. Pairwise pseudonymous identifiers are used across governance contexts where cross-system linkage is not required. Automated audits periodically scan governance logs for attribute leakage. Third-party credential integrations are reviewed for minimisation compliance.

Advanced Implementation — All intermediate capabilities plus: BBS+ verifiable credentials with unlinkable selective disclosure for external and cross-boundary flows. Zero-knowledge predicate proofs for threshold decisions. The attribute requirement mapping is enforced at the governance platform boundary — attributes outside the mapping are rejected, not just filtered. Independent privacy audit confirms that no unnecessary attributes are processed, logged, or transmitted. The organisation can demonstrate to data protection authorities that credential presentation minimisation is structurally enforced, not policy-dependent.

7. Evidence Requirements

Required artefacts:

• Attribute requirement mapping. Formal documentation mapping each governance action type to the minimum identity attributes required. Format: structured table or configuration export.
• Identity provider configuration. Evidence that the identity provider is configured to release only the required attributes for each governance relying party. Format: configuration export or automated test results.
• Governance log schema. Schema definition for governance logs demonstrating that only required attributes are included. No fields for unnecessary attributes.
• Selective disclosure implementation evidence. Where SD-JWT, BBS+, or ZKP mechanisms are implemented, configuration and test evidence demonstrating that credential holders can present only the required attributes.
• Attribute leakage audit results. Results from periodic (at least annual) audits of governance logs and credential flows verifying that no unnecessary attributes are being processed or stored.

Retention requirements:

• Attribute requirement mapping and audit results: minimum 5 years for regulated sectors; minimum 3 years otherwise. Governance logs with minimised attributes follow the retention requirements of the governance actions they record.

Access requirements:

• Producible to data protection authorities or auditors within 48 hours of request.

8. Test Specification

Test 8.1: Attribute Filtering Enforcement

• Stimulus: Present a credential assertion containing 15 attributes to the governance system, where the attribute requirement mapping specifies only 3 attributes are required for the requested action.
• Expected behaviour: The governance system processes only the 3 required attributes. The remaining 12 are not logged, stored, or forwarded.
• Pass criteria: Governance log entries for the action contain only the 3 required attributes. No trace of the other 12 attributes exists in any system log.
• Fail criteria: Any non-required attribute appears in any governance log or downstream system.

Test 8.2: Selective Disclosure Enforcement

• Stimulus: Using SD-JWT or equivalent, request a governance authentication that requires only {role, proofing_level}. Verify that the credential holder can present only these attributes.
• Expected behaviour: The credential holder's client presents an SD-JWT disclosing only {role, proofing_level}. The governance system verifies the signature and accepts the authentication.
• Pass criteria: Only the requested attributes are disclosed. The governance system does not receive undisclosed attributes.
• Fail criteria: The full credential is transmitted despite selective disclosure being available.

Test 8.3: Persistent Identifier Isolation

• Stimulus: The same credential holder authenticates to two unrelated governance contexts (e.g., agent mandate approval and separate audit log access). Compare the identifiers used in each context.
• Expected behaviour: Different pairwise pseudonymous identifiers are used in each context. Cross-context correlation is not possible without access to the identity provider's mapping.
• Pass criteria: Identifiers differ across contexts. No persistent identifier enables cross-context tracking.
• Fail criteria: The same persistent identifier (e.g., employee email) appears in both contexts.

Test 8.4: Predicate Proof for Threshold Decision

• Stimulus: A governance action requires proof that the actor's proofing level ≥ IAL2. Verify that the system accepts a predicate proof ("proofing_level ≥ IAL2") without revealing the exact proofing level.
• Expected behaviour: The governance system accepts the predicate proof. The exact proofing level (e.g., IAL3) is not disclosed to or logged by the governance system.
• Pass criteria: The governance decision is made based on the predicate. The exact attribute value is not logged.
• Fail criteria: The exact proofing level is disclosed or logged despite predicate proof being available.

Test 8.5: Governance Log Attribute Leakage Scan

• Stimulus: Run an automated scan of governance logs accumulated over 30 days, searching for attributes that are not in the attribute requirement mapping for each logged event type.
• Expected behaviour: No non-required attributes are found in any governance log entry.
• Pass criteria: Zero attribute leakage detected.
• Fail criteria: Any non-required attribute is found in any governance log entry.

Test 8.6: Third-Party Credential Minimisation

• Stimulus: Integrate a third-party identity provider that, by default, includes 20 attributes in its assertions. Verify that the governance system's integration configuration limits the received attributes to the required minimum.
• Expected behaviour: The integration is configured with an explicit attribute request list. Only the required attributes are received and processed.
• Pass criteria: The governance system receives only the required attributes from the third-party provider.
• Fail criteria: Non-required attributes from the third-party provider are received and processed.

Conformance Scoring

• Score 0: No credential minimisation — full credential assertions are processed and logged with all available attributes.
• Score 1: An attribute requirement mapping exists but is not technically enforced — filtering is advisory and relies on identity provider configuration.
• Score 2: Attribute filtering is enforced at the governance system boundary. Selective disclosure mechanisms are used for internal flows. Governance logs contain only required attributes. Periodic attribute leakage audits are conducted.
• Score 3: All Score 2 capabilities plus: BBS+ or equivalent unlinkable selective disclosure for external flows. Zero-knowledge predicate proofs for threshold decisions. Pairwise pseudonymous identifiers. Independent privacy audit confirming structural enforcement.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
GDPR	Article 5(1)(c) (Data Minimisation)	Direct requirement
GDPR	Article 25 (Data Protection by Design and by Default)	Direct requirement
eIDAS 2.0	Article 6a(4) (Selective Disclosure)	Direct requirement
EU AI Act	Article 10(5) (Data Governance — Proportionality)	Supports compliance
CCPA/CPRA	Section 1798.100(c) (Purpose Limitation)	Supports compliance
ISO 27701	Section 7.4 (PII Minimisation)	Supports compliance
NIST Privacy Framework	CT.DM-P1 (Data Minimisation)	Supports compliance

GDPR — Article 5(1)(c) (Data Minimisation)

Article 5(1)(c) requires that personal data is "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." AG-284 directly implements this principle for credential presentations in agent governance. Every unnecessary attribute in a governance credential is personal data processed beyond what is necessary, constituting a violation.

GDPR — Article 25 (Data Protection by Design and by Default)

Article 25 requires data protection to be built into systems by design, with privacy-friendly defaults. AG-284's requirement for attribute requirement mapping, selective disclosure, and governance log filtering implements data protection by design. The default must be minimum disclosure, not full credential presentation.

eIDAS 2.0 — Article 6a(4) (Selective Disclosure)

eIDAS 2.0 explicitly requires that European Digital Identity Wallets support selective disclosure — users must be able to present only the attributes required for a specific transaction. AG-284 ensures that agent governance systems are designed to consume selectively disclosed credentials, completing the minimisation chain from wallet to governance system.

CCPA/CPRA — Section 1798.100(c) (Purpose Limitation)

The CPRA strengthens purpose limitation requirements, prohibiting collection of personal information beyond what is reasonably necessary for the disclosed purpose. For agent governance, the disclosed purpose is governance decision-making — attributes beyond what the decision requires are collected beyond the necessary scope.

10. Failure Severity

Field	Value
Severity Rating	Medium
Blast Radius	Data-scoped — the impact scales with the number of over-disclosed attributes, the number of credential presentations, and the sensitivity of the unnecessarily disclosed data

Consequence chain: Failure of credential presentation minimisation results in unnecessary accumulation of personal data and sensitive attributes across governance systems. The immediate consequence is expanded attack surface — governance logs containing national insurance numbers, home addresses, or biometric references become high-value targets that they would not be if they contained only role and proofing level. The regulatory consequence includes GDPR Article 5(1)(c) violations, which the ICO has enforced with fines ranging from £100,000 to £4,400,000 depending on the scope and sensitivity of the over-processed data. The operational consequence includes increased data governance burden — every unnecessary attribute in the governance log must be governed, retained, protected, and eventually deleted under data subject rights. The reputational consequence arises when a breach exposes personal data that should never have been collected. The failure compounds over time: each credential presentation adds unnecessary data, and the accumulation creates escalating risk.

Cross-references: AG-279 (Human Identity Proofing Governance) establishes the identity that AG-284 minimises the disclosure of. AG-029 (Credential Integrity Verification) ensures the credential is uncompromised; AG-284 ensures it discloses only what is needed. AG-280 (Service Identity Proofing Governance) should similarly apply minimisation to service credential presentations. AG-286 (Attested Login Context Governance) must balance the need for context evidence against AG-284's minimisation principle. AG-287 (Non-Repudiation Evidence Governance) must retain sufficient evidence for non-repudiation without over-retaining identity attributes. AG-288 (Shared Account Prohibition Governance) depends on individual identity; AG-284 ensures that individual identity is proven with minimum attribute disclosure.