# SITEBORNE Trust and Security

SITEBORNE keeps different kinds of authority distinct. No single artifact is automatically authority for everything.

## Authority model

The public model separates:
- identity;
- mandate;
- policy;
- payment authorization;
- execution authority;
- result authorization;
- proof/evidence;
- settlement authority.

Core invariants:
- `RESULT EXISTENCE != RESULT AUTHORIZATION`
- `PAYMENT RECEIPT != SETTLEMENT AUTHORITY`
- `PCC != PERMISSION`
- `SUPPLIER CAPABILITY != QUALIFICATION`
- `PAYMENT != IDENTITY`
- `EXECUTION SUCCESS != CONTRACT SATISFACTION`

PCC is evidence/proof of what happened. It is not automatically identity authority, result-access authority, payment authority, or settlement authority.

## Current live production

Current public paid v2 routes do not establish caller identity merely because an x402 payment is authorized. Payment authorization is economic evidence only.

Buyer private keys remain client-side. The public live contract delivers paid results in the paid response and exposes no general result-retrieval route. Live runtime/OpenAPI truth remains authoritative.

Do not infer Release 3 candidate result-authorization semantics as already active in production.

## Release 3 candidate result authorization

Release 3 introduces governed result-authorization semantics for sensitive candidate services.

- `document_evidence_json.v3` — `BUYER_AUTHORIZED`
- `verify_agent_output.v3` — `BUYER_AUTHORIZED`

Public candidate services use contract-governed output handling.

A payment receipt does not automatically authorize result access. Service execution does not automatically authorize result retrieval.

## Vulnerability reporting

Authorized reporting contact for the next release:

`security@alerts.siteborne.net`

This build includes the product RFC 9116 artifact at `/.well-known/security.txt`:

- `Contact: mailto:security@alerts.siteborne.net`
- `Expires: 2027-08-31T23:59:59Z`
- `Canonical: https://siteborne.com/.well-known/security.txt`
- `Preferred-Languages: en`
- `Policy: https://siteborne.com/security`

Configuration and authorization do **not** prove:
- external mailbox deliverability;
- reply-path behavior;
- active monitoring;
- 24/7 coverage;
- SLA;
- safe harbor;
- bug bounty;
- live publication/read-back.

Those remain external operational verification tasks.

## Public-safe boundary

The website does not expose private scoring, qualification thresholds, provider-selection heuristics, private Evidence Graph structure, credentials, internal routing logic, private policy-compiler behavior, or economic margin/exposure mechanics.

External trust/observer systems provide evidence only and never become canonical SITEBORNE authority.


## Fresh external propagation snapshot — 2026-09-24 UTC

Current public observation is intentionally kept separate from SITEBORNE authority.

- Fresh runtime readiness reports `status=ready`, `phase=production`, and paid production services active.
- `siteborne.net` still states that paid services are disabled by policy. This is first-party publication drift and should be reconciled; it does not override runtime state.
- Agenstry observes A2A 1.0, 8 declared skills, x402 metadata, machine/search discovery, and 100% 30-day uptime. Its mutable trust/owner fields have varied across current indexed views, so those scores are not canonical SITEBORNE facts.
- MCPMetrics observes 6 MCP tools and 79/79 successful probes over its current 30-day window, with p50 latency around 706 ms.
- Glama independently observes 6 tools and a healthy endpoint, but its longer-window uptime differs materially from MCPMetrics; the two measurements are preserved rather than averaged.
- Small Print tracks two registry versions, 11 semantic changes in one release, and 0 recorded public advisories at this observation.
- PluginBench exposes the official registry identifier `net.siteborne/utility` and direct Streamable HTTP configuration.
- Mcprush currently misinterprets the server as 0 tools / free. Treat this as observer/parser drift, not SITEBORNE runtime truth.
- FastDrop currently records repeated probe failures despite successful observations by other MCP observers. This is a monitoring/probe-compatibility conflict requiring re-check.
- Search indexes still expose some historical SITEBORNE paths/copy, so search identity convergence is incomplete.
- No confirmed public chain transaction, third-party package integration, or organic community adoption signal was established in the searched sources. Absence of evidence is not evidence of nonexistence.

Machine-readable evidence and monitoring configuration:
- `/osint-snapshot.json`
- `/monitoring-manifest.json`

External observers are evidence only. They never become execution, release, pricing, settlement, or semantic authority.