Akashik Protocol
Specification v0.1.0-draft

Security

Authentication, authority hierarchy, and memory unit visibility rules.

Authentication Requirements by Level

LevelRequirement
0No authentication required. Suitable for single-user, local deployments.
1Authentication RECOMMENDED. Agent identity SHOULD be verified at REGISTER.
2Token-based authentication REQUIRED. All operations MUST include a valid token.
3Full authentication REQUIRED (token, certificate, or OAuth). Authority hierarchy enforced.

Authority Hierarchy (Level 3)

At Level 3, operations are gated by the authority level of the requesting agent. The Field MUST enforce the authority hierarchy on all privileged operations.

Authority LevelRoleCapabilities
10Human OperatorOverride any decision, resolve any conflict, purge memory
8Session CreatorCancel tasks, pause sessions, set session-level policies
6Senior AgentMerge conflicts, create tasks for other agents
4Standard AgentRECORD, ATTUNE, DETECT, manage own tasks
2Observer AgentATTUNE (read-only), SUBSCRIBE (receive only)
0Audit AgentREPLAY (read historical data only)

Agents declare their authority level during REGISTER. The Field MUST verify the claimed authority level against the authentication credential.

Privileged Operation Requirements

OperationMinimum Authority
REGISTERAny
RECORD (committed)4+
RECORD (draft)2+
ATTUNE2+
DETECT4+
MERGE (standard strategies)6+
MERGE (human_escalation resolution)10
COMPACT (archive)6+
COMPACT (purge)10
DEREGISTER (own agent)4+
DEREGISTER (another agent)8+

Memory Unit Visibility (Level 3)

At Level 3, not all agents can see all memory units. Visibility is determined by three overlapping rules, applied in order:

1. Session Membership

Agents MUST only see memory units from sessions they are a member of, unless the Field is configured to allow cross-session visibility.

2. Role-Based Rules

Session creators MAY configure role-based visibility rules per session. Example:

{
  "session_id": "session-q1-strategy",
  "visibility_rules": [
    { "role": "observer", "allowed_types": ["finding", "decision"] },
    { "role": "strategist", "allowed_types": ["*"] }
  ]
}

3. Authority-Level Restrictions

Memory units of type human_directive are visible only to agents with authority level 4 or higher. This prevents lower-authority agents from acting on directives they are not authorized to see.


Token-Based Authentication (Level 2+)

At Level 2, all operations MUST include an authentication token. The token MUST be passed in the message envelope or in the transport header (implementation-defined).

HTTP binding: Include the token as a Bearer token in the Authorization header:

Authorization: Bearer <token>

Native SDK: Pass the token during Field initialization:

const field = new Field({ authToken: process.env.AKASHIK_TOKEN });

The Field MUST reject any operation (except REGISTER at Level 2) from an agent without a valid token with HTTP 401 Unauthorized or the appropriate protocol-level error.


Security Considerations

Level 0 Deployments. Level 0 fields have no authentication and are appropriate only for single-user local development. They MUST NOT be exposed on a network accessible to untrusted parties.

Agent ID Spoofing. Without authentication, any client can claim any agent_id. Level 2+ implementations MUST validate agent identity via the auth token at registration time.

Event Log Integrity. The append-only event log MUST NOT be modifiable after entries are written. Implementations SHOULD use checksums or cryptographic signatures on log entries at Level 2+.

Cross-Session Leakage. Level 3 implementations MUST enforce session boundaries in ATTUNE queries. An agent in Session A MUST NOT receive memory units from Session B unless cross-session visibility is explicitly configured.