HYBRID DEVNET · PUBLIC EVIDENCE LIVEVerifiable infrastructure for value, markets, identity, and operational dataInspect the network

Security & privacy

What should stay on our server rather than in a browser or AI agent?

3 min read

Keep service credentials and privileged integration decisions in a trusted environment. An AI proposal should be evaluated within an approved identity and policy context, not receive a private key or the ability to substitute arbitrary authority identifiers.

Give each environment only what it needs

A browser is where users interact; an agent interprets information and proposes actions; a trusted server can hold appropriate service credentials and enforce integration checks. These roles should not automatically share the same access. Keep privileged credentials out of public client code and agent prompts. Treat values supplied by a browser or model as requests to validate, not as proof that the caller owns the named wallet or may use its authority.

Keep customer authorization separate

Moving a service credential to a server does not mean moving the customer’s password, passkey, or private signing material there. Follow the specific authorized protocol for those elements. The server should establish the permitted identity, resource relationship, and operation scope rather than accepting arbitrary authority identifiers from an untrusted proposal. A useful AI integration lets the agent describe what it wants while the trusted workflow determines what is actually allowed.

Test information leaks and unauthorized substitution

Review logs, error messages, screenshots, and request bodies for secrets or unnecessary personal information. Test whether a caller can substitute another resource identifier and obtain a result it should not see. Keep decision-only evaluation separate from execution even when they appear in one user journey. Name the owner of credential rotation and incident response. Clear trust boundaries make the application safer to operate and give developers a concrete checklist beyond the general instruction to “secure the API.”

Illustrative example

A server checks the workload binding and permitted scope before forwarding a proposal for decision-only evaluation.

In plain language

Share references, not secrets

A public reference helps someone locate a record without giving them control of it. Examples include an Explorer URL, a transaction hash, a record identifier, and the network name. A secret can provide access or signing power and must be handled differently. Passwords, access tokens, recovery material, and private signing shares do not belong in a support ticket, screenshot, chat message, or public log. Even public identifiers can reveal business activity when combined with other information, so share only what the recipient needs. Before sending a screenshot, check for account details, customer names, browser tokens, and unrelated transactions. A request to “verify your wallet” does not justify revealing recovery material. Use established contact channels and the authorized account workflow. Protecting private information is compatible with transparent evidence: the goal is to demonstrate the relevant fact without publishing everything that sits behind it.

In plain language

Permission, signing, and completion are different

Think of a business bank payment: preparing the instruction, approving it, and seeing it complete are separate events. A wallet workflow also has distinct responsibilities. Authorization means the required person or policy permits a particular action. Signing means the participating systems produce the cryptographic signature needed for that action. Completion means the relevant system has accepted or settled the result under its rules. A screen displaying a wallet, or a service responding successfully, does not combine these steps into one. In Hybrid-Chain, customer authorization is separate from distributed signing participation. When reviewing a status, ask which of these stages it describes, which asset and network it concerns, and whether the evidence is current. This distinction helps prevent a common mistake: treating an informational record as permission to move money. An operator should be able to explain the stage in ordinary language without asking you to share any secret material.

Conditions & limitations

This does not mean moving customer passwords, passkeys, or signing material to your application server. Their handling must follow the specific authorized wallet protocol.

What to do next

Review credential storage, scope checks, customer authorization, and untrusted inputs as separate integration boundaries.

Developer prerequisites ↗AI evaluation guide ↗