Evidence Before Authority
Evidence is a prerequisite for trust. A public claim remains bounded by its source, maturity, limitation, and review context.
SECURITY NOTICE
Official Source and Anti-Impersonation Notice
fenrua.ai is the sole and only official website for Fenrua Protocol and Fenrua Labs Pty Ltd.
Any website, social account, media channel, token page, contract listing, claim page, airdrop page, staking page, swap, bridge, NFT mint, Telegram group, Discord server, or public communication claiming to represent Fenrua Protocol must be treated as unofficial unless it is explicitly listed or linked from fenrua.ai.
Fenrua Protocol has no live token, contract, presale, airdrop, staking pool, swap, bridge, NFT mint, or claim page on Ethereum, Solana, BSC, or any other public mainnet chain.
Fenrua activity is currently limited to Fenrua’s private-chain research environment and bounded public evidence surfaces. Fenrua Labs Pty Ltd is not offering, selling, promoting, or authorising any commercial token offering.
Any public token, contract, listing, website, media profile, message, group, or account claiming to represent a live Fenrua token or an official Fenrua commercial offering should be treated as unauthorised, impersonated, or potentially fraudulent unless explicitly confirmed on fenrua.ai.
Always verify Fenrua information from fenrua.ai before trusting any external link, message, contract address, social post, or media account.
TRUST BOUNDARIES
Trust
Fenrua BlackBox Protocol provides bounded evidence for reviewer verification while keeping private AI execution outside the public/private disclosure boundary. Public trust is expressed through scoped claims, evidence classes, release records, and explicit non-claims—not a generic assurance badge.
PUBLIC GOVERNANCE MODEL
Trust Gate: Capability Is Not Authority
A model's ability to produce an action does not mean the action should be trusted.
Fenrua's Trust Gate direction separates AI capability from execution authority. Tool calls, model decisions, network actions, infrastructure changes, and release claims should be evaluated through bounded evidence before they become trusted operational actions.
Capability is not authority
A tool permission is not the same as operational trust. Raw capability does not collapse identity, policy, evidence, verification, containment, and recovery.
ALLOW is not EXECUTE
An allowed condition does not itself execute an action. Review, stop authority, and escalation remain separate from capability.
Read the authority boundaryAUTHORITY BOUNDARY
ALLOW is not EXECUTE
A Trust Gate direction is a governance model for review; it is not an instruction path, a public executor, or a runtime control surface.
A log is not enough unless it can prove the relevant identity, request, policy, revocation state, and evidence boundary.
An action can be allowed within a bounded decision context while still requiring review, a separate executor, an explicit stop condition, or escalation.
REVIEWER PATH
Inspect the action boundary before treating it as authority
This is a high-level public reviewer path. It describes the records and boundaries a reviewer should expect, not a public implementation workflow.
Action Request
An AI-linked action, tool call, model decision, infrastructure change, or release claim is proposed for review.
Identity and Scope
The action is tied to an authorised identity, tenant or context boundary, and permitted surface.
Manifest and Policy
The declared manifest, policy state, route scope, capability boundary, and current maturity are checked together.
Revocation and Deny-Overrides
Revoked, denied, expired, or superseded authority remains a separate stop condition.
Evidence Construction
The action produces bounded evidence rather than relying on assertion alone.
Verification
Relevant evidence can be inspected against its public or tenant-scoped boundary.
Review / Stop / Escalation
ALLOW is not EXECUTE. Review, stop authority, and escalation remain separate from raw capability.
MATURITY BOUNDARY
Current public state and staged direction are separate
Public records are inspectable today. Future Trust Gate capabilities remain promotion-gated until matching public evidence and release conditions exist.
Current public state
Fenrua publishes a public evidence interface, claim and capability registers, a release manifest, a local validation path, bounded observation context, public/private disclosure boundaries, and documented Trust Gate model and promotion-gated direction.
- Public records remain source-bound and limitation-aware.
- Local validation reproduces the public static surface only.
- Bounded observations remain separate from runtime authority.
Roadmap direction
The Local Trust Gate CLI and hosted verifier have no public interface. Tenant identity, agent capture, proof ingress, challenge and replay protocol, and production rollout gates remain staged direction.
- No tenant identity system is represented as live.
- No agent capture pipeline or proof ingress is represented as live.
- No challenge, replay, or production rollout feature is represented as live.
Boundary: This Trust Gate page describes Fenrua's public governance model and staged protocol direction. It does not claim that all Trust Gate tooling, tenant identity, proof ingress, challenge/replay, or hosted verifier features are live unless explicitly marked as live on fenrua.ai.
AUTONOMOUS AI RISK CONTEXT
Review the authority path, not capability alone
Autonomous AI systems can pursue narrow objectives across tool, network, and infrastructure boundaries. Fenrua addresses the governance class behind that risk: raw capability becoming unreviewed operational authority.
A sandbox alone is not enough if a capable system can find a path around it. A tool permission alone is not enough if the action is not tied to policy. A log alone is not enough if it cannot prove which identity, manifest, request, revocation state, and evidence boundary made the action acceptable.
Fenrua does not claim to prevent every misuse of autonomous AI. It provides a protocol direction for bounding, evidencing, reviewing, and challenging the actions that matter.
MACHINE-READABLE RECORDS
Trace public statements to their boundary
Claims link to capability and evidence records. Stronger assurance language is governed by a versioned public contract rather than presentation alone.
LIMITATIONS
Separate release, observation, and runtime evidence
A release manifest binds listed public artifacts. A signed observation has its own bounded contract. Neither establishes system-wide safety, authorization, or independent certification.
Static artifact binding
Use the release verification route to inspect commit, artifact, method, exclusions, and expiration boundaries.
Release verificationBounded public monitor
Signed observations remain separate from release records and are evaluated only under their declared key, sequence, and freshness semantics.
Status monitorPrivate vulnerability path
Security reporting uses the published private contact boundary and does not turn public documentation into a security certification.
Security reporting