Trust

Intelligence can recommend.
It cannot grant permission.

Conflux MCP separates discovery from authority, evidence from decision, and decision from execution. This page shows exactly how.

VerificationProvenanceSecurityAuthorizationAudit
01 / Verification

What has actually been checked.

Every published capability carries a verification record. It names the stages that ran, the outcome of each stage, and the verifier. A server without a VERIFIED record cannot be PUBLISHED. Verification is a fact with a provenance, not a marketing claim.

Manifest validation

Identity, version, capabilities, sources.

Schema validation

Every field conforms to the Part 5 contract.

Identity validation

Server identity and version are real.

Capability validation

Declared capabilities match the manifest.

Source validation

Every declared source is reachable.

Artifact integrity

Published artifacts match their hashes.

Protocol compatibility

MCP transport and version.

Security checks

No forbidden patterns, no credential exposure.

Provenance completeness

Repository, license, and publisher.

02 / Provenance

Where every capability comes from.

Every server carries a source record: repository, license, publisher, publication timestamp, and the exact version that was verified. When a new version appears, it is a new record with a new verification. Old versions remain auditable.

Publisher

Who owns the server.

Repository

Where the code lives.

License

Under what terms it may be used.

Sources

Which external data sources the server declares.

Version

Which exact version was verified and published.

03 / Security

How the boundary is enforced.

Conflux MCP treats every MCP server as untrusted input. Capabilities declare their access level — READ_ONLY, ADVISORY, STATE_CHANGING, or TRANSACTIONAL — and that declaration drives what the authority layer will permit.

READ_ONLY

No state change. Safe to expose broadly.

ADVISORY

Recommendations only. No automatic action.

STATE_CHANGING

Requires explicit authority and approval.

TRANSACTIONAL

Requires explicit authority, approval, and policy.

04 / Authorization

Who is permitted to do what.

Authorization is separate from intelligence. A recommendation is not a permission. An approval is not an authorization. A catalogue listing is not an authorization. Authority is explicit, bounded, and enforced before any MCP operation executes.

Identity

Authenticated subject and tenant.

Authority

Explicit, bounded grant of permitted scope.

Policy

Deterministic decision on each specific action.

Approval

Where required by policy, a bound, time-limited grant.

Execution gate

The single point at which a request becomes real.

05 / Audit

What happened, and how you can prove it.

Every material decision is recorded. Identity, authority, policy, approval, execution, and outcome are all anchored with hashes that make the record tamper-evident. Audit is not a log. It is evidence.

Admissions

Every gate decision, with reason codes.

Executions

Every MCP operation, with its bound token.

Approvals

Every grant of permission, with its obligation.

Lifecycle events

Every state transition of every server.

Chain integrity

Each record commits to the previous one.

See it in the marketplaceBuild on it