API CREDENTIAL · MODEL
Application
In the intended model, an API credential would authorize an application to make scoped REST API requests within an approved project and environment boundary.
CREDENTIALS · DEVELOPER SURFACE · PREVIEW
Scoped. Masked.
Governed.
This page describes the intended credential model for future authenticated API and MCP access. It is an explanatory preview, not a live issuance surface, and it does not imply production credentials, authenticated Console access, or generally available API/MCP access.
AVAILABILITY STATE
Credential issuance is not represented as generally available. All lifecycle, scope, environment, rotation, revocation, and audit behavior below is an intended model subject to implementation and qualification.
CREDENTIAL TYPES
Two interface models. One bounded-access principle.
API and MCP credentials are presented here as intended authorization models for different interfaces. Neither type is represented as currently issuable from this public surface.
MCP CREDENTIAL · MODEL
AI Agent
In the intended model, an MCP credential would authorize an AI agent to invoke an approved set of Veritan tools within a defined identity, project, and evidence boundary.
INTENDED LIFECYCLE
Create. Protect. Separate. Rotate. Revoke.
The sequence below is the target lifecycle contract. It is not evidence that the authenticated credential service is live today.
01 · Create with explicit scope
The intended lifecycle begins with an explicit capability scope rather than an unbounded credential. Exact production scope names remain subject to implementation and qualification.
02 · Display once
The design target is a display-once issuance event: the raw value would be presented at creation and not retrievable later from the public or authenticated management surface.
03 · Store outside the product surface
The intended operator responsibility is to place the issued value in an appropriate secrets-management system. Veritan is designed around retaining only the information required to recognize and govern the credential without re-exposing the raw value.
04 · Bind to an environment
The intended model separates development and production authority. The exact enforcement mechanism is part of the authenticated platform build and is not represented as live on this public page.
05 · Rotate deliberately
Rotation is an intended lifecycle operation. Final grace-window behavior, cutover semantics, and zero-downtime guarantees are not represented as production commitments on this preview surface.
06 · Revoke when required
Revocation is an intended lifecycle operation. Exact propagation timing, request rejection behavior, and audit persistence remain implementation details to be qualified before general availability.
EXAMPLE FORMAT
Illustrative only. No production namespace implied.
The neutral example below demonstrates how a bearer credential might appear in documentation. It is not a real credential, production prefix, endpoint contract, or availability claim.
EXAMPLE — MASKED — NON-LIVEHTTP MODEL
# Illustrative credential only
# vrtn_example_••••••••••••••••••••••••
# Illustrative request shape — not a live endpoint contract
POST /v1/example/verify
Authorization: Bearer vrtn_example_••••••••••••••••••••••••
Content-Type: application/json
{
"record_id": "<example-record-id>"
}PLATFORM EXPERIENCE PREVIEW — ILLUSTRATIVE MODEL ONLY — NO LIVE CREDENTIALS ISSUED FROM THIS SURFACE
ILLUSTRATIVE SCOPE MODEL
Capabilities are expected to be explicit.
The names below are examples of how narrowly bounded capabilities may be expressed. They are not a published production scope registry or guarantee of future naming.
records.verify
Illustrative capability for requesting verification of authorized records.
records.read
Illustrative capability for reading authorized record metadata and state.
records.write
Illustrative capability for creating or updating records within an approved project boundary.
evidence.read
Illustrative capability for reading evidence linked to authorized records.
authority.read
Illustrative capability for reading authority information within an approved scope.
provenance.read
Illustrative capability for reading provenance information within an approved scope.
audit.read
Illustrative capability for reading audit information if exposed by the qualified platform.
events.manage
Illustrative capability for managing event-delivery configuration if and when that surface becomes available.
DESIGN PRINCIPLES
Target properties, not present-tense operational claims.
These principles describe the intended security posture of the future authenticated credential system. Qualification evidence will determine when each may be stated as implemented behavior.
DISPLAY ONCE
Design target: present the raw credential value once at creation and avoid later plaintext retrieval. The authenticated implementation is not yet represented as generally available.
ENVIRONMENT ISOLATION
Design target: bind credential authority to an explicit environment so development and production authority cannot be treated as interchangeable.
SCOPE AS CONTRACT
Design target: treat a credential as a bounded capability contract rather than a master key. Final production scope vocabulary remains subject to qualification.
CONTROLLED ROTATION
Design target: support deliberate credential replacement without presenting an unqualified zero-downtime guarantee.
AUDITABLE LIFECYCLE
Design target: make credential creation, rotation, and revocation attributable and inspectable through the canonical audit/evidence system once the authenticated platform is qualified.
NO PLAINTEXT RE-EXPOSURE
Design target: avoid returning the raw credential value after issuance and keep credential material out of logs, error messages, and ordinary management responses.
CREDENTIAL MODEL PRINCIPLE
Credential authority should be bounded, attributable, revocable, and no broader than the integration requires.