Human conversation plane
Approved beta clientExchange end-to-end encrypted human messages when the implementation is enabled.
GSC Bicameral
BetaGSC Bicameral separates confidential human conversations from controlled human-to-agent commands. It gives teams encrypted messaging for sensitive discussions and a governed approval path for AI-assisted workflows.
Beta operating manual
GSC Bicameral beta security manual
Use Bicameral’s human and agent planes only through an approved beta client, preserving the cryptographic and approval boundary between them.
Audience, scope, and prerequisites
Covers security expectations and controlled workflows for Bicameral foundation deployments. The verified repository contains backend and relay services but no reviewable end-user client or completed cryptographic WASM package, so no production confidentiality claim should be inferred from this manual.
Who this is for
- Approved beta participants
- Human reviewers of agent commands
- Bicameral security operators
Before you sign in
- An approved beta client and named security owner
- Verified participant identity and device trust
- A documented agent-command approval policy
- A fallback communication channel for security incidents
Roles and responsibilities
| Role | Access | Responsibilities |
|---|---|---|
| Human participant | Use the approved human conversation plane when the client and cryptography are enabled. |
|
| Command requester or approver | Submit or review structured agent-plane requests. |
|
| Security operator | Operate identity, relay, audit, and Gatekeeper services. |
|
Use the human conversation plane
The human plane is intended to keep agent services outside plaintext conversations and key material.
Verify a human contact and device
Confirm identity and cryptographic safety state before exchanging sensitive content.
- 1Use an approved client
Do not use an unofficial build or direct relay connection.
- 2Open contact identity
Check that the participant is marked HUMAN and matches the expected organizational identity.
- 3Verify safety information
Compare the provided device or safety identifier through a separate trusted channel when the client exposes it.
- 4Resolve changes
Stop sensitive messaging when a device, key, or identity indicator changes unexpectedly.
Expected result
The participant has a verified human identity and understood device/key state before sensitive messaging begins.
Send a human-plane message
Keep human discussion separate from executable agent instructions.
- 1Confirm the plane
Check the visible Sanctuary or human-plane indicator.
- 2Confirm recipients
Review every participant and device-state warning.
- 3Write minimum-necessary content
Do not include secrets or data prohibited by policy even when encryption is enabled.
- 4Send and verify state
Use the client’s delivery and safety indicators; do not infer delivery from relay availability alone.
Expected result
The approved client submits ciphertext for the intended human recipients without treating the text as an agent instruction.
Request and approve agent actions
An agent-plane request is an executable proposal, not ordinary chat; the human approver remains accountable for scope and outcome.
Create an agent command
State a bounded objective, inputs, allowed systems, and prohibited effects.
- 1Switch to the command plane
Confirm the UI identifies the destination as an AGENT or governed workflow.
- 2Define the objective
State the desired result, affected records, time range, and success criteria.
- 3Limit authority
Specify allowed tools and systems and exclude destructive, external, or sensitive actions unless explicitly approved.
- 4Review generated plan
Check identities, destinations, data scope, side effects, and rollback before submission.
- 5Submit for approval
Do not bypass or self-approve when separation of duties applies.
Expected result
A structured, bounded request enters the approval queue without accessing human-plane plaintext or keys.
Review an agent approval
Approve only when the exact action, data, authority, and expected effect are understood.
- 1Verify requester and agent
Confirm immutable HUMAN and AGENT identities and tenant.
- 2Inspect the full proposal
Review tool calls, targets, parameters, data exposure, external messages, and destructive effects.
- 3Compare with policy
Check authorization, separation of duties, change window, and evidence requirements.
- 4Approve, deny, or return
Deny ambiguous scope; require a revised request rather than editing intent mentally.
- 5Review completion evidence
Confirm actual effects and preserve the approval and execution record.
Expected result
Only an explicitly authorized command executes and its approval and outcome remain auditable.
Security and data handling
- Keep human conversation and agent command planes visibly and technically separate.
- Never give agents human-plane private keys or decrypted conversation content.
- Verify human, agent, and device identity before trust.
- Require explicit human approval for consequential agent actions.
- Stop use on unexpected key, identity, plane, or approval-state changes.
Known limitations
Read before relying on an unsupported workflow
These limits describe the source-pinned GSC Bicameral 0.1.0 foundation scope and must be rechecked when the product changes.
- The verified source is version 0.1.0 foundation; the roadmap places H2H MVP, enhanced messaging, agent orchestration, Gatekeeper, and production audit at later milestones.
- No end-user frontend or completed cryptographic client is present in the verified repository.
- Backend storage and relay components alone do not provide end-to-end security.
- Marketing descriptions of post-quantum messaging must not be treated as implemented certification.
- Gatekeeper workflows are deployment-specific and require separate authorization.
Troubleshooting
You cannot sign in to GSC Bicameral
Likely cause: The session expired, the identity is not assigned to the application, or the tenant claim is missing.
- Open the application from the approved portal and complete sign-in again.
- Confirm that the correct organizational identity and tenant are selected.
- If access is still denied, record the time and request an entitlement check from support.
A documented action or navigation item is not visible
Likely cause: The current role, release, tenant configuration, or feature flag does not expose that operation.
- Confirm the role and prerequisites listed for the procedure.
- Reload the page after signing in again; do not attempt to bypass the interface through direct URLs.
- Ask the product owner whether the feature is enabled for the tenant before reporting a defect.
A saved change or background operation is not visible
Likely cause: Validation failed, processing is still running, or the current view is stale or filtered.
- Review inline validation, status indicators, filters, and the selected tenant or workspace.
- Refresh once and search for the item by its stable name or identifier.
- Do not repeat irreversible or externally visible actions until the original operation status is known.
Identity, device, or safety information changes
Likely cause: A legitimate device rotation, client reset, account change, or active impersonation may have occurred.
- Stop sensitive communication and agent approvals.
- Verify the participant through a separate trusted channel.
- Have the security operator review identity and key events before trust is restored.
An agent action is pending or completed unexpectedly
Likely cause: The request was ambiguous, approval state is stale, or a workflow executed outside the expected client state.
- Do not approve or resubmit.
- Preserve request, approval, agent, and audit identifiers.
- Escalate to the security operator and review external side effects.
Contact support
Contact support when
- A repeatable GSC Bicameral error blocks an approved workflow
- Expected data, permissions, or tenant boundaries appear incorrect
- A security, privacy, compliance, or data-loss concern is suspected
- A key, identity, device, or plane-separation concern occurs
- An agent action may have executed without valid approval
- The deployment’s cryptographic readiness cannot be demonstrated
Include
- The page, action, and expected result
- The exact error text and time of occurrence, including time zone
- Your tenant, role, browser, and a sanitized record or item identifier
- Whether the problem can be reproduced and which troubleshooting steps were tried
Never include
- Passwords, access tokens, API keys, recovery codes, or session cookies
- Unredacted personal, health, financial, or other regulated data
- Private encryption keys or complete confidential documents unless an approved channel is provided