/** * SecurityPolicy — declarative per-call gate for executeCode. * * Today executeCode accepts allowlist + timeout + memory + env directly * as fields on the request. That's fine for a single caller but as soon * as multiple callers exist (broker, RPC, CLI, hooks) it becomes * tempting to forget one knob and ship a permissive default. * * SecurityPolicy is the named bundle: pick a profile by name (tight, * standard, broad), or build one from the policy primitives. The * broker integration (commit 4 follow-up) maps each agent's permission * mode to a profile; the user can override with explicit overrides. * * Profiles in increasing capability: * * tight — no tool calls; only log + exit. Useful for "let the * model write a calculation that runs locally and reports * back" — pure compute, no side effects. * read-only — Read, Grep, Glob, Web search. No file writes, no Bash. * 15s timeout, 256MB mem, no network env. * standard — read-only + Edit + Write + Bash (allowlisted commands). * 30s timeout, 512MB mem, scrubbed env. * broad — standard + arbitrary Bash + browser + computer-use. * 60s timeout, 1024MB mem. Should require explicit user * approval before each invocation. */ import type { StubToolSpec } from "./stub-generator.js"; export type SecurityProfileName = "tight" | "read-only" | "standard" | "broad"; export interface SecurityPolicy { readonly profile: SecurityProfileName; readonly allowedTools: ReadonlyArray; readonly timeoutMs: number; readonly memoryMb: number; readonly envAllowlist: ReadonlyArray; readonly requiresApproval: boolean; } export declare function getSecurityPolicy(profile: SecurityProfileName): SecurityPolicy; export declare function listProfiles(): readonly SecurityProfileName[]; /** Build a custom policy. The base profile sets defaults; overrides win. */ export declare function customPolicy(base: SecurityProfileName, overrides: Partial>): SecurityPolicy;