How it works
From your first sign-in to a verified receipt.
Two things happen every time you use the Trust Plane: your account and credential stay recoverable, and every governed request leaves evidence instead of an unverified claim. Here is how both fit together as one journey.
Your onboarding journey
Start with Google
Sign in at /customer. Google establishes a durable, recoverable identity for your account, the Trust Plane receives only a provider-issued account identifier, not your Google password, mail, or files. Signing in again from any browser restores the same account.
Run the bounded assessment
Before you connect anything, use the free assessment to check your public Agent Card and declared operating controls. It reviews interface details and declarations you provide; it does not ingest repositories, message bodies, credentials, or customer records, and it does not claim your production system is safe on its own.
Choose a plan and check out
Pick Builder, Team, or Managed from your account page. The browser reuses the same checkout request key when retrying a failed request. Paid access only appears after a verified payment event arrives. A return-page query string is never treated as proof of payment.
Create your agent credential
Issue a scoped API credential from your account. It is shown once, is not stored in your browser, and the service keeps only its hash and lifecycle metadata afterward. If it is lost, sign back in, issue a replacement, and separately revoke the lost credential by ID. Issuing a replacement does not revoke an existing credential.
Run your first synthetic proof
Run the synthetic continuity demonstration from your account. It consumes one governed operation and exercises the same checkpoint, approval, and verification path a real workflow would use, without touching your production agents.
Self-service credentials currently cover operating-profile assessments and synthetic proofs. Gateway execution against your own agents and multi-agent workflows require separately configured permissions, contact jovan@the825.co to scope that work.
What happens inside one governed request
Once you or your agent calls a skill, the same bounded path runs every time:
Registered destination
The gateway only routes to agents already recorded in the private registry, with an owning team, environment, and sensitivity ceiling.
Schema-checked request
Your input is validated against that skill's declared JSON Schema before anything runs.
Approval binding
Skills that require approval bind the exact operation and arguments to that approval. A different authenticated person resolves it; a stale or mismatched approval is rejected, not reused.
Bounded execution
An idempotency key prevents a retry from duplicating an effect, and the call runs under fixed time and response-size limits.
Evidence, not a claim
The result is reduced to bounded evidence and a digest. Where independent verification is required, a separate principal checks the outcome before it counts as complete.
Audit receipt
The whole chain lands in an append-only, digest-chained log that
/v1/audit/verifycan confirm has not been altered.
Continue
Read the product overview and case studies · Compare plans · Review security and privacy · Start with Google