Memory · Vault

Sensitive information needs its own place.

Vault memory stores credentials, tokens, and other sensitive values with encryption and controlled access. Keep them separate from ordinary conversation memory, and let authorized parts of your application retrieve them when needed.

Vault memory

The reference is visible. The value is protected.

Vault/ Access request
Example workspace
STORED REFERENCE

calendar.service_key

Scheduling integration

SensitivityHighValueNot displayed
REQUESTING IDENTITY
Requested operationRead value
PermissionAllowed

Available to the authorized task.

The example operation may use the credential. Its value stays hidden here.

Example request · authorization passedValue never shown in this demo

Keep access intentional.

Return a sensitive value only to the authorized operation. Keep it out of casual conversation and logs, and review vault access.

Choose a chapter to explore

Example permission check with no stored credential. Connect access rules and key custody to your deployment.

Protected storage

Keep access intentional.

An agent may need a service credential to do its work. The vault gives that credential a named, encrypted record with a sensitivity level, so access can be managed separately from the rest of its memory.

01

Encrypt stored values

AES-256-GCM protects the stored content and checks that encrypted data has not been altered.

02

Label sensitivity

Mark entries by sensitivity so your application can apply the appropriate access policy.

03

Manage key custody

Connect the vault’s encryption keys to the key management and lifecycle policies for your deployment.

04

Retrieve deliberately

Keep a record reference for authorized operations, and handle decrypted values only within your application’s protected execution path.

05

Review access

The vault engine records operations for auditing, including access and security events.

06

Apply access controls

The secure vault interface checks user permissions and clearance before allowing operations.

Developer example

Store the value. Keep its reference.

Use a signed capability scoped to vault writes. This server-side example stores an internal-sensitivity value and keeps its returned record ID for later reference.

Store a protected value through the vault HTTP interfacetypescript
// Run server-side with credentials scoped to this Mind.
const endpoint = process.env.AKASHA_URL;
const capability = process.env.AKASHA_CAPABILITY;
if (!endpoint || !capability) throw new Error("Configure your Mind connection");

async function request(method: string, path: string, body?: unknown) {
  const headers: Record<string, string> = {
    "Content-Type": "application/json",
    "x-akasha-capability": capability!,
  };
  if (process.env.AKASHA_TOKEN) {
    headers.Authorization = "Bearer " + process.env.AKASHA_TOKEN;
  }
  const response = await fetch(new URL(path, endpoint), {
    method, headers,
    body: body === undefined ? undefined : JSON.stringify(body),
  });
  if (!response.ok) throw new Error("Mind request failed: " + response.status);
  return response.json();
}

const value = process.env.SERVICE_CREDENTIAL;
if (!value) throw new Error("Supply the credential from your secret store");
const stored = await request("POST", "/v1/memory/vault", {
  key: "service.credential",
  data_b64: Buffer.from(value, "utf8").toString("base64"),
  sensitivity: "internal",
});
// Keep stored.id as the reference. Do not log the credential.
// Base64 is transport encoding; the vault engine handles encryption.
Under the hood

Protection you can inspect.

Vault
Stored-value encryption
AES-256-GCM
Secure engine access
user permissions and clearance checks
Audit
operation and security-event logging
Example sensitivity
internal
HTTP store
key · data_b64 · sensitivity

Give sensitive data the treatment it needs.

Use a dedicated vault for the credentials and protected values behind your agent’s work.