Onboard a consumer

Use this sequence for one real consumer.

Keep every value-free declaration under review.

Do not copy a production alias inventory into an example.

Read Configuration for field schemas.

Read Verification for live proof requirements.

1. Name the consumer and alias

Choose a stable consumer name.

Choose one flat alias, such as secret://example/default.

Keep the alias as a name only.

Do not place a credential value in the alias registry.

An alias identifies custody data.

It does not grant access by itself.

2. Define the policy rule

Create a rule for the consumer's workload and destination.

Bind the method and path that the consumer needs.

List only the aliases that the rule may inject.

Set require_placeholder: true for credentialed routes.

Keep the policy default as deny.

Do not add approval, spend, or semantic permission fields.

Those decisions belong to an external authority system.

3. Select custody

Choose a backend that the consumer cannot inspect.

Use the environment backend for disposable local development only.

Use Keychain on supported local systems.

Use a systemd credential directory for a deployed Linux broker.

Do not put a raw value in policy, aliases, consumer configuration, or source.

Do not pass a raw value as a command argument.

Mint resolves the alias inside the broker.

4. Replace the consumer credential

Repoint the consumer to the Mint proxy base URL.

Place a placeholder where the credential value was expected.

Use this synthetic form in examples:

Authorization: Bearer __mint.example.default__

Keep the consumer's destination explicit.

Do not add a generic secret retrieval call.

5. Prove the deny path

First run the allowed request with the placeholder.

Confirm the intended receiver records one request.

Then remove the matching policy rule or use an unmatched path.

Repeat the request with the same placeholder.

Expect 403.

Confirm that the receiver records no new request.

Confirm that Mint did not resolve the alias for the denied call.

A valid capability from a non-loopback peer must also fail in development mode.

The loopback authenticator enforces that boundary.

6. Scan the consumer configuration

Run the metadata-only adoption scan.

mint adoption scan --boundaries path/to/credential-boundaries.yaml

The scan reports names, paths, classifications, and severity.

It does not print values, lengths, or value-derived fingerprints.

Fix raw literals, runtime keychain commands, and undeclared environment references.

Keep provider-native OAuth in its native store.

Declare that exception exactly in the boundary manifest.

7. Record evidence

Run mint doctor against the effective configuration.

Pass --self-test-alias to test custody without printing its value.

Run the live brokered request and the deny proof.

Record a secret-free Mint receipt.

Record a vendor-side or receiver-side receipt when possible.

Add the consumer to the adoption inventory.

Set posture from evidence kinds, not a hand-written status.

Use an HTTPS URL or an absolute local path for each receipt.

Do not record credentials, hashes derived from values, or private deployment coordinates.

8. Recheck after cutover

Remove the former direct credential path.

Run the scanner again.

Run the allow and deny requests again.

Confirm fresh evidence for both outcomes.

An adoption declaration alone does not prove live use.