@vellumai/assistant 0.5.6 → 0.5.7

package/docs/architecture/keychain-broker.md

@@ -1,264 +1,69 @@
-# macOS Keychain Broker Architecture
+# macOS Keychain Broker Architecture (Legacy)
 
-**Status:** Accepted
-**Last Updated:** 2026-03-14
+**Status:** Superseded by CES credential routing
+**Last Updated:** 2026-03-22
 **Owners:** macOS client + assistant runtime
 
-## Decision
+## Current State
 
-Embed the keychain broker in the macOS app process rather than running a standalone daemon. The app exposes SecItem keychain operations over a Unix domain socket to the assistant runtime and gateway. Debug builds skip the broker entirely (`#if !DEBUG` guard) so developers never see keychain authorization prompts during rebuilds.
+The daemon no longer uses the keychain broker for credential operations. Credential storage is routed through the Credential Execution Service (CES):
 
-Credential storage is abstracted behind a `CredentialBackend` interface with two implementations: a keychain backend (backed by the broker) and an encrypted file store backend. Each process resolves a single primary backend at startup and uses single-writer semantics -- all writes go to the resolved backend only, with no dual-writing.
+1. **CES RPC** (primary) -- stdio RPC to the CES process. Default path for all local modes (desktop app, dev, CLI).
+2. **CES HTTP** -- containerized/Docker/managed mode via `CES_CREDENTIAL_URL`.
+3. **Encrypted file store** (fallback) -- used when CES is unavailable.
 
-## Problem Statement
+See [`assistant/docs/credential-execution-service.md`](../credential-execution-service.md) for the current credential architecture.
 
-We want macOS to use Keychain as the primary secret store, but direct keychain access from the daemon process causes repeated authorization prompts. The prompts are especially problematic during development with ad-hoc signed builds, where every rebuild changes the signing identity and triggers a new keychain prompt.
+### What remains
 
-Prior state:
+The keychain broker is not fully deleted. These components still exist:
 
-- macOS defaulted to encrypted file storage to avoid prompt fatigue: `assistant/src/security/secure-keys.ts`.
-- Historical comments documented prompt issues with ad-hoc signing: `clients/shared/App/SigningIdentityManager.swift`.
-- The `keychain.ts` module (now deleted) called `/usr/bin/security` CLI, which was unreliable and prompt-heavy.
+| Component | Location | Why it exists |
+|---|---|---|
+| Keychain broker client | `assistant/src/security/keychain-broker-client.ts` | Used only by workspace migrations 015 and 016 |
+| Migration 015 | `assistant/src/workspace/migrations/015-migrate-credentials-to-keychain.ts` | Historical migration that copied encrypted store credentials into keychain |
+| Migration 016 | `assistant/src/workspace/migrations/016-migrate-credentials-from-keychain.ts` | Reverse migration that copies keychain credentials back to the encrypted store for CES unification |
+| Swift broker server | `clients/macos/vellum-assistant/Security/KeychainBrokerServer.swift` | UDS server in the macOS app; still compiled for release builds (`#if !DEBUG`) |
+| Swift broker service | `clients/macos/vellum-assistant/Security/KeychainBrokerService.swift` | `SecItem*` wrapper used by the broker server |
+| Gateway credential reader | `gateway/src/credential-reader.ts` | Still tries the keychain broker as a secondary fallback after CES, before the encrypted store |
 
-## Architecture
+The broker client and Swift server remain because migrations 015/016 must be able to read/write the keychain for users who previously stored credentials there. These migrations are append-only and cannot be removed. The gateway's broker fallback provides a read path for credentials that may still be in the keychain during the migration window.
 
-### CredentialBackend interface
+### What was removed
 
-All credential storage operations are routed through the `CredentialBackend` interface, which provides a uniform API for get, set, delete, and list operations. This abstraction decouples `secure-keys.ts` from any specific storage mechanism.
+- **`KeychainBackend`** class and `createKeychainBackend()` factory -- the daemon's `CredentialBackend` implementation that wrapped the broker client. Removed from `credential-backend.ts`.
+- **`resolveBackendAsync()` keychain resolution path** -- the daemon no longer considers `VELLUM_DESKTOP_APP` or `VELLUM_DEV` for backend selection. Backend resolution in `secure-keys.ts` now follows the CES RPC > CES HTTP > encrypted store priority.
+- **Dual-writing and broker-unavailable commit behavior** -- the daemon previously committed to the keychain backend even when the broker socket was unreachable, causing operations to fail visibly. This behavior is gone; CES RPC is the primary backend with encrypted store as a graceful fallback.
 
-Two implementations exist:
+## Original Design (Historical)
 
-| Backend          | Backing store                                | When used                                                               |
-| ---------------- | -------------------------------------------- | ----------------------------------------------------------------------- |
-| Keychain backend | macOS Keychain via the broker UDS connection | Production app context (`VELLUM_DEV` is NOT `"1"`) and broker available |
-| Encrypted store  | `~/.vellum/protected/keys.enc` (AES-256-GCM) | `VELLUM_DEV=1`, broker unavailable, CLI-only, headless, CI              |
+The sections below document the original broker architecture for historical reference. They describe behavior that is no longer active in the daemon's credential resolution path.
 
-The interface is intentionally minimal to make adding future backends trivial -- e.g., Linux secret service (libsecret/D-Bus), 1Password CLI, or cloud KMS. A new backend only needs to implement the `CredentialBackend` interface and be wired into the backend resolution logic.
+### Original problem
 
-### Broker topology
+Direct keychain access from the daemon process caused repeated macOS authorization prompts, especially during development with ad-hoc signed builds where every rebuild changed the signing identity.
 
-```mermaid
-graph LR
-    subgraph "macOS App Process"
-        SERVER["KeychainBrokerServer<br/>(NWListener on UDS)"]
-        SERVICE["KeychainBrokerService<br/>(SecItem* wrapper)"]
-        SERVER --> SERVICE
-        SERVICE --> KC["macOS Keychain"]
-    end
+### Original topology
 
-    subgraph "Backend Resolution"
-        RESOLVE{"resolveBackend()"}
-        KB["Keychain Backend"]
-        EB["Encrypted Store Backend"]
-        RESOLVE -->|"VELLUM_DEV!=1<br/>+ broker available"| KB
-        RESOLVE -->|"VELLUM_DEV=1<br/>OR broker unavailable"| EB
-    end
+The macOS app embedded a `KeychainBrokerServer` (NWListener on a Unix domain socket) that accepted JSON requests from the daemon and gateway, validated an auth token, and dispatched to `KeychainBrokerService` (a thin `SecItem*` wrapper). The daemon resolved either the keychain backend or encrypted store at startup based on `VELLUM_DESKTOP_APP` and `VELLUM_DEV` environment variables.
 
-    KB -->|"UDS JSON"| SERVER
-    RUNTIME["Assistant Runtime (Bun)"] --> RESOLVE
-    GATEWAY["Gateway (Bun)"] -->|"read-only"| RESOLVE
+### Message contract
 
-    EB --> ENC["Encrypted Store<br/>(~/.vellum/protected/keys.enc)"]
-```
+Transport: Unix domain socket at `~/.vellum/keychain-broker.sock`, newline-delimited JSON.
 
-### Key properties
+| Method | Params | Result |
+|---|---|---|
+| `broker.ping` | none | `{ pong: true }` |
+| `key.get` | `{ account }` | `{ found, value? }` |
+| `key.set` | `{ account, value }` | `{ stored: true }` |
+| `key.delete` | `{ account }` | `{ deleted: true }` |
+| `key.list` | none | `{ accounts: string[] }` |
 
-- **No separate process lifecycle.** The broker starts when the app starts and stops when the app stops. No launchd plist, no health checks, no orphan cleanup.
-- **No auth bootstrap problem.** The app writes the broker auth token to disk before launching the daemon, so the daemon always has a valid token at startup.
-- **No keychain prompts on signed builds.** Items are stored with `kSecAttrAccessibleAfterFirstUnlock` under the `vellum-assistant` service name. A stable code-signing identity means macOS grants access without prompting after the first unlock.
-- **No keychain interaction on debug builds.** The entire `KeychainBrokerServer` is compiled out with `#if !DEBUG`, so development builds use the encrypted file store exclusively.
-- **Single-writer to resolved backend.** Each process resolves exactly one primary backend at startup. Writes go only to that backend. There is no dual-writing.
-- **Encrypted file store as permanent fallback.** CLI-only, headless, and development environments always have the encrypted store (`~/.vellum/protected/keys.enc`) available.
+This protocol is still used by migrations 015/016 via the broker client.
 
-## Components
+### Security model
 
-### Swift side (macOS app)
-
-| File                                                                  | Role                                                                                                                                                                             |
-| --------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `clients/macos/vellum-assistant/Security/KeychainBrokerServer.swift`  | UDS server using `NWListener`. Accepts newline-delimited JSON requests, validates auth token, dispatches to `KeychainBrokerService`. Compiled only for `!DEBUG` builds.          |
-| `clients/macos/vellum-assistant/Security/KeychainBrokerService.swift` | Thin `SecItem*` wrapper scoped to the `vellum-assistant` service. Provides `get`, `set`, `delete`, `list`. Uses `kSecAttrAccessibleAfterFirstUnlock`. Compiled only for `macOS`. |
-
-### TypeScript side (runtime + gateway)
-
-| File                                               | Role                                                                                                                                                                                                                                                                                                                                                          |
-| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `assistant/src/security/credential-backend.ts`     | `CredentialBackend` interface definition (`get`, `set`, `delete`, `list`) plus both adapter implementations: `KeychainBackend` (backed by the broker UDS client) and `EncryptedStoreBackend` (backed by `encrypted-store.ts` / `~/.vellum/protected/keys.enc`). Also exports factory functions `createKeychainBackend()` and `createEncryptedStoreBackend()`. |
-| `assistant/src/security/keychain-broker-client.ts` | Async UDS client for the runtime. Persistent socket connection, request/response correlation, auth token caching with auto-refresh on `UNAUTHORIZED`. Falls back gracefully (returns safe defaults, never throws).                                                                                                                                            |
-| `assistant/src/security/secure-keys.ts`            | Unified API surface. Resolves a single primary `CredentialBackend` at startup based on environment and broker availability. All writes go to the resolved backend only (single-writer). Reads check the primary backend first, with legacy fallback to the encrypted store for migration. Deletes clean up both stores to prevent stale keys.                 |
-| `gateway/src/credential-reader.ts`                 | Read-only credential reader. Tries broker via native async UDS connection (`node:net`), falls back to encrypted store. All public credential read functions are async.                                                                                                                                                                                        |
-
-## Message Contract
-
-### Transport
-
-- Unix domain socket: `~/.vellum/keychain-broker.sock`
-- Socket path is derived from the data directory (e.g., `join(getRootDir(), "keychain-broker.sock")`)
-- Newline-delimited JSON (`\n` as message boundary)
-
-### Request envelope
-
-```json
-{
-  "v": 1,
-  "id": "uuid",
-  "token": "hex-auth-token",
-  "method": "key.get",
-  "params": { "account": "anthropic" }
-}
-```
-
-The `v` field is a protocol version number (currently `1`). The server rejects requests with unsupported versions.
-
-### Response envelope
-
-Success:
-
-```json
-{
-  "id": "uuid",
-  "ok": true,
-  "result": { "found": true, "value": "sk-..." }
-}
-```
-
-Error:
-
-```json
-{
-  "id": "uuid",
-  "ok": false,
-  "error": { "code": "UNAUTHORIZED", "message": "Invalid auth token" }
-}
-```
-
-### Methods
-
-| Method        | Params               | Result                   |
-| ------------- | -------------------- | ------------------------ |
-| `broker.ping` | none                 | `{ pong: true }`         |
-| `key.get`     | `{ account }`        | `{ found, value? }`      |
-| `key.set`     | `{ account, value }` | `{ stored: true }`       |
-| `key.delete`  | `{ account }`        | `{ deleted: true }`      |
-| `key.list`    | none                 | `{ accounts: string[] }` |
-
-### Error codes
-
-- `UNAUTHORIZED` — invalid or missing auth token
-- `INVALID_REQUEST` — malformed request, missing params, or unsupported protocol version
-- `KEYCHAIN_ERROR` — SecItem operation failed
-
-## Security Model
-
-### Authentication
-
-1. On app launch, the broker generates 32 random bytes via `SecRandomCopyBytes` and hex-encodes them as the auth token.
-2. The token is written to `~/.vellum/protected/keychain-broker.token` with `0600` permissions. The parent directory is `0700`.
-3. Every request must include the token. Requests with missing or invalid tokens are rejected before method dispatch.
-4. If the app restarts (new token), the TS client detects `UNAUTHORIZED`, re-reads the token from disk, and retries once.
-
-### Process boundary
-
-- The UDS itself restricts access to local processes.
-- The token file's `0600` permissions restrict readers to the same user.
-- Together: only same-user local processes that can read the token file can authenticate.
-
-### Keychain access control
-
-- All items use `kSecAttrAccessibleAfterFirstUnlock` — secrets survive screen lock without re-prompting.
-- All items are scoped to the `vellum-assistant` service name via `kSecAttrService`.
-- On signed release builds, the stable code-signing identity means macOS trusts the app to access its own keychain items without prompting.
-
-### Threat model
-
-| Threat                                      | Mitigation                                                                                 |
-| ------------------------------------------- | ------------------------------------------------------------------------------------------ |
-| Other-user process reads secrets            | UDS + token file `0600` restrict to same user                                              |
-| Malicious local process impersonates broker | Client reads token from a known file path; attacker would need same-user file write access |
-| Stale socket from unclean exit              | Server calls `unlink()` on the socket path before binding                                  |
-| App restart invalidates cached token        | Client detects `UNAUTHORIZED`, re-reads token, retries once                                |
-
-### Future: XPC transport
-
-XPC provides stronger caller identity guarantees via audit tokens and code requirement checks. This would replace the file-based auth token with kernel-enforced caller verification, preventing same-user impersonation. No timeline — the UDS + token model is sufficient for the current threat profile.
-
-## Developer Experience
-
-- **Debug builds:** The `#if !DEBUG` guard compiles out the entire `KeychainBrokerServer`. The broker socket is not created, so clients see the broker as unavailable and use the encrypted store. Developers never encounter keychain prompts during the edit-build-run cycle.
-- **Release builds:** The broker starts automatically with the app. The daemon discovers the broker via the derived socket path (`join(getRootDir(), "keychain-broker.sock")`) and token file. No configuration needed.
-- **CLI-only / headless:** No macOS app means no broker socket. All storage uses the encrypted file store. This is the expected path for CI, servers, and non-macOS platforms.
-
-## Store-Routing Policy
-
-### Backend resolution
-
-At process startup, `secure-keys.ts` resolves a single primary `CredentialBackend` for the lifetime of the process:
-
-| Condition                                             | Resolved backend |
-| ----------------------------------------------------- | ---------------- |
-| `VELLUM_DEV` is NOT `"1"` **and** broker is available | Keychain backend |
-| `VELLUM_DEV=1` **or** broker is unavailable           | Encrypted store  |
-
-Once resolved, the backend does not change during the process lifetime. There is no runtime switching between backends.
-
-### Read strategy
-
-Reads go to the **primary backend first**. If the primary backend is the keychain backend and the key is not found, a legacy fallback read is attempted against the encrypted store. This fallback handles the migration period where keys written before the single-writer policy may still exist only in the encrypted store. When the primary backend is the encrypted store, there is no fallback -- the encrypted store is the sole source of truth.
-
-### Write strategy
-
-Writes go **only to the resolved primary backend**. There is no dual-writing. This eliminates the consistency problems that dual-writing introduced (partial failures leaving stores out of sync, unclear source of truth).
-
-- Keychain backend resolved: writes go to the keychain via broker only.
-- Encrypted store resolved: writes go to the encrypted file store only.
-
-### Delete strategy
-
-Deletes **always clean up both stores** regardless of the resolved backend. This ensures that stale keys do not linger in the non-primary store, which could cause unexpected reads through the legacy fallback path.
-
-### `VELLUM_DEV` environment variable
-
-Setting `VELLUM_DEV=1` forces the encrypted store as the sole backend, bypassing the keychain broker entirely even when the broker socket is available. This serves two purposes:
-
-1. **Development ergonomics.** Developers running the daemon outside the macOS app context (e.g., `bun run` directly) avoid broker connectivity issues and keychain prompt noise.
-2. **Deterministic testing.** Tests and CI environments get predictable encrypted-store-only behavior without depending on macOS Keychain infrastructure.
-
-When `VELLUM_DEV` is not set or is set to any value other than `"1"`, backend resolution proceeds normally (broker availability check).
-
-## Callsite Policy
-
-### Async-only policy
-
-**All credential access uses the async functions** (`getSecureKeyAsync`, `setSecureKeyAsync`, `deleteSecureKeyAsync`). These route through the resolved `CredentialBackend`, with legacy fallback reads to the encrypted store when the keychain backend is primary. The migration from sync to async is complete: the sync variants (`getSecureKey`, `setSecureKey`, `deleteSecureKey`) have been deleted and no longer exist in the codebase.
-
-### Runtime request handlers (secret-routes, etc.)
-
-All runtime HTTP handlers that write or delete secrets use the async APIs (`setSecureKeyAsync`, `deleteSecureKeyAsync`). These are the primary entry points for macOS app flows and route through the resolved backend.
-
-### Gateway (credential-reader)
-
-The gateway reads credentials via async `readCredential()` which tries the broker first (native async UDS), falling back to the encrypted store. The gateway never writes credentials -- that responsibility belongs to the assistant runtime.
-
-### Sync function removal
-
-The sync secure-key functions (`getSecureKey`, `setSecureKey`, `deleteSecureKey`) have been deleted. All code uses the async variants (`getSecureKeyAsync`, `setSecureKeyAsync`, `deleteSecureKeyAsync`).
-
-## Migration
-
-Existing encrypted store keys remain accessible through the legacy read fallback. When the keychain backend is the resolved primary, reads that miss in the keychain fall back to the encrypted store, so keys written before the single-writer policy are still reachable without a one-time migration step.
-
-Over time, as keys are re-written through normal credential update flows, they will be written only to the resolved primary backend. The legacy fallback read path will eventually become a no-op as all keys migrate naturally to the keychain.
-
-Deletes always clean up both stores, so stale keys in the non-primary store are removed as part of normal credential lifecycle operations.
-
-The old `keychain.ts` module (which called `/usr/bin/security` CLI directly) has been deleted. The old keychain-to-encrypted migration code has been removed. All keychain access now flows exclusively through the broker.
-
-## Extensibility
-
-The `CredentialBackend` interface is the extension point for adding new storage backends. To add a new backend (e.g., Linux secret service via libsecret/D-Bus, 1Password CLI, cloud KMS):
-
-1. Implement the `CredentialBackend` interface in a new module.
-2. Wire the new backend into the resolution logic in `secure-keys.ts`.
-3. The rest of the codebase is unaffected -- all callers go through the existing async API surface.
-
-No changes to callsites, the gateway, or the broker protocol are needed when adding a backend.
+- Auth token: 32 random bytes via `SecRandomCopyBytes`, written to `~/.vellum/protected/keychain-broker.token` (0600).
+- UDS restricts to local processes; token file restricts to same user.
+- Keychain items use `kSecAttrAccessibleAfterFirstUnlock` under the `vellum-assistant` service name.
+- Debug builds compile out the entire broker server (`#if !DEBUG`).

package/docs/architecture/security.md

@@ -249,22 +249,6 @@ sequenceDiagram
     end
 ```
 
-### Secret Ingress Blocking
-
-```mermaid
-graph TB
-    MSG["Inbound user_message / task_submit"] --> CHECK{"secretDetection.enabled<br/>+ blockIngress == true?"}
-    CHECK -->|no| PASS["Pass through to session"]
-    CHECK -->|yes| SCAN["scanText(content)<br/>regex + entropy detection"]
-    SCAN --> MATCH{"Matches found?"}
-    MATCH -->|no| PASS
-    MATCH -->|yes| BLOCK["Block message"]
-    BLOCK --> NOTIFY["Send error to client:<br/>'Message contains sensitive info'"]
-    BLOCK --> LOG["Log warning with<br/>detectedTypes + matchCount<br/>(never the secret itself)"]
-```
-
-The secret scanner includes pattern-based detection for Telegram bot tokens (format: `<8-10 digit bot_id>:<35-char secret>`), API keys from major providers, Slack tokens, and other common secret formats. This prevents users from accidentally pasting a Telegram bot token in chat — the token must be entered through the secure credential prompt flow or the Settings UI instead.
-
 ### Brokered Credential Use
 
 ```mermaid
@@ -305,7 +289,6 @@ The `allowOneTimeSend` config gate (default: `false`) enables a secondary "Send
 | `assistant/src/tools/credentials/policy-validate.ts` | Policy input validation (allowedTools, allowedDomains)                |
 | `assistant/src/permissions/secret-prompter.ts`       | HTTP secret_request/secret_response flow                              |
 | `assistant/src/security/secret-scanner.ts`           | Regex + entropy-based secret detection                                |
-| `assistant/src/security/secret-ingress.ts`           | Inbound message secret blocking                                       |
 | `clients/macos/.../SecretPromptManager.swift`        | Floating panel UI for secure credential entry                         |
 
 ---

package/docs/credential-execution-service.md

@@ -251,11 +251,11 @@ To dark-launch CES in managed deployments without user impact:
 
 1. **Deploy the CES container image** via the `credential_executor_image` field in `POST /v1/internal/assistant-image-releases/`. The warm-pool manager picks it up and includes it in pod templates. The CES container starts, binds its bootstrap socket and health port (8090), but does nothing until an assistant connects.
 
-2. **Verify sidecar health** using kubelet probes: `/healthz` (liveness) and `/readyz` (readiness, always returns 200; includes `rpcConnected` field for observability). CES reports its protocol version in both probe responses.
+2. **Verify sidecar health** using kubelet probes: `/healthz` (liveness, returns `{"status": "ok"}`) and `/readyz` (readiness, always returns 200; includes `rpcConnected` field for observability).
 
 3. **Enable `ces-tools`** first on a test cohort. The assistant spawns a local CES child process and registers tools. Verify tool registration, grant creation, and audit logging work end-to-end without affecting existing workflows.
 
-4. **Enable `ces-managed-sidecar`** on the same cohort. The assistant switches from child-process transport to the bootstrap Unix socket. CES `/readyz` always returns 200; check the `rpcConnected` field in the response body to verify the assistant has connected.
+4. **Enable `ces-managed-sidecar`** on the same cohort. The assistant switches from child-process transport to the bootstrap Unix socket. CES `/readyz` always returns 200 with `{"status": "ok", "rpcConnected": <boolean>}`; check the `rpcConnected` field to verify the assistant has connected.
 
 5. **Progressive rollout**: Widen the cohort by enabling flags on more assistants. Monitor for grant failures, materializer errors, and egress proxy issues.
 

package/node_modules/@vellumai/ces-contracts/package.json

@@ -2,6 +2,7 @@
   "name": "@vellumai/ces-contracts",
   "version": "0.0.1",
   "private": true,
+  "license": "MIT",
   "type": "module",
   "exports": {
     ".": "./src/index.ts",

package/node_modules/@vellumai/ces-contracts/src/rpc.ts

@@ -25,6 +25,12 @@
  *
  * **Lifecycle**
  * - `update_managed_credential` — Push an updated API key to CES after hatch
+ *
+ * **Credential CRUD**
+ * - `get_credential` — Retrieve a credential by account name
+ * - `set_credential` — Store or update a credential
+ * - `delete_credential` — Delete a credential by account name
+ * - `list_credentials` — List all credential account names
  */
 
 import { z } from "zod/v4";
@@ -51,6 +57,14 @@ export const CesRpcMethod = {
   ListAuditRecords: "list_audit_records",
   /** Push an updated assistant credential to CES after post-hatch provisioning. */
   UpdateManagedCredential: "update_managed_credential",
+  /** Retrieve a single credential by account name. */
+  GetCredential: "get_credential",
+  /** Store or update a credential by account name. */
+  SetCredential: "set_credential",
+  /** Delete a credential by account name. */
+  DeleteCredential: "delete_credential",
+  /** List all credential account names. */
+  ListCredentials: "list_credentials",
 } as const;
 
 export type CesRpcMethod =
@@ -421,6 +435,79 @@ export type UpdateManagedCredentialResponse = z.infer<
   typeof UpdateManagedCredentialResponseSchema
 >;
 
+// ---------------------------------------------------------------------------
+// get_credential
+// ---------------------------------------------------------------------------
+
+export const GetCredentialSchema = z.object({
+  /** The account name to look up. */
+  account: z.string(),
+});
+export type GetCredential = z.infer<typeof GetCredentialSchema>;
+
+export const GetCredentialResponseSchema = z.object({
+  /** Whether the credential was found. */
+  found: z.boolean(),
+  /** The credential value (present only when found). */
+  value: z.string().optional(),
+});
+export type GetCredentialResponse = z.infer<
+  typeof GetCredentialResponseSchema
+>;
+
+// ---------------------------------------------------------------------------
+// set_credential
+// ---------------------------------------------------------------------------
+
+export const SetCredentialSchema = z.object({
+  /** The account name to store the credential under. */
+  account: z.string(),
+  /** The credential value to store. */
+  value: z.string(),
+});
+export type SetCredential = z.infer<typeof SetCredentialSchema>;
+
+export const SetCredentialResponseSchema = z.object({
+  /** Whether the credential was successfully stored. */
+  ok: z.boolean(),
+});
+export type SetCredentialResponse = z.infer<
+  typeof SetCredentialResponseSchema
+>;
+
+// ---------------------------------------------------------------------------
+// delete_credential
+// ---------------------------------------------------------------------------
+
+export const DeleteCredentialSchema = z.object({
+  /** The account name to delete. */
+  account: z.string(),
+});
+export type DeleteCredential = z.infer<typeof DeleteCredentialSchema>;
+
+export const DeleteCredentialResponseSchema = z.object({
+  /** The result of the delete operation. */
+  result: z.enum(["deleted", "not-found", "error"]),
+});
+export type DeleteCredentialResponse = z.infer<
+  typeof DeleteCredentialResponseSchema
+>;
+
+// ---------------------------------------------------------------------------
+// list_credentials
+// ---------------------------------------------------------------------------
+
+export const ListCredentialsSchema = z.object({});
+export type ListCredentials = z.infer<typeof ListCredentialsSchema>;
+
+export const ListCredentialsResponseSchema = z.object({
+  /** The account names of all stored credentials. */
+  accounts: z.array(z.string()),
+});
+export type ListCredentialsResponse = z.infer<
+  typeof ListCredentialsResponseSchema
+>;
+
 // ---------------------------------------------------------------------------
 // Full RPC contract type map
 // ---------------------------------------------------------------------------
@@ -466,6 +553,22 @@ export interface CesRpcContract {
     request: UpdateManagedCredential;
     response: UpdateManagedCredentialResponse;
   };
+  [CesRpcMethod.GetCredential]: {
+    request: GetCredential;
+    response: GetCredentialResponse;
+  };
+  [CesRpcMethod.SetCredential]: {
+    request: SetCredential;
+    response: SetCredentialResponse;
+  };
+  [CesRpcMethod.DeleteCredential]: {
+    request: DeleteCredential;
+    response: DeleteCredentialResponse;
+  };
+  [CesRpcMethod.ListCredentials]: {
+    request: ListCredentials;
+    response: ListCredentialsResponse;
+  };
 }
 
 /**
@@ -508,4 +611,20 @@ export const CesRpcSchemas = {
     request: UpdateManagedCredentialSchema,
     response: UpdateManagedCredentialResponseSchema,
   },
+  [CesRpcMethod.GetCredential]: {
+    request: GetCredentialSchema,
+    response: GetCredentialResponseSchema,
+  },
+  [CesRpcMethod.SetCredential]: {
+    request: SetCredentialSchema,
+    response: SetCredentialResponseSchema,
+  },
+  [CesRpcMethod.DeleteCredential]: {
+    request: DeleteCredentialSchema,
+    response: DeleteCredentialResponseSchema,
+  },
+  [CesRpcMethod.ListCredentials]: {
+    request: ListCredentialsSchema,
+    response: ListCredentialsResponseSchema,
+  },
 } as const;

package/node_modules/@vellumai/credential-storage/package.json

@@ -2,6 +2,7 @@
   "name": "@vellumai/credential-storage",
   "version": "0.0.1",
   "private": true,
+  "license": "MIT",
   "type": "module",
   "exports": {
     ".": "./src/index.ts"

package/node_modules/@vellumai/egress-proxy/package.json

@@ -2,6 +2,7 @@
   "name": "@vellumai/egress-proxy",
   "version": "0.0.1",
   "private": true,
+  "license": "MIT",
   "type": "module",
   "exports": {
     ".": "./src/index.ts"

package/package.json

@@ -1,6 +1,7 @@
 {
   "name": "@vellumai/assistant",
-  "version": "0.5.6",
+  "version": "0.5.7",
+  "license": "MIT",
   "type": "module",
   "exports": {
     ".": "./src/index.ts"
@@ -28,7 +29,6 @@
   },
   "dependencies": {
     "@agentclientprotocol/sdk": "^0.16.1",
-    "@anthropic-ai/claude-agent-sdk": "^0.2.42",
     "@anthropic-ai/sdk": "^0.78.0",
     "@google/genai": "^1.40.0",
     "@modelcontextprotocol/sdk": "^1.15.1",
@@ -70,7 +70,6 @@
     "@vellumai/egress-proxy"
   ],
   "devDependencies": {
-    "@pydantic/logfire-node": "^0.13.0",
     "@types/archiver": "^7.0.0",
     "@types/bun": "^1.2.4",
     "@types/node": "^25.2.2",