InkOS

InkOS runs as the local OS user but gives the model no shell and no generic file access: every tool goes through one harness runtime that checks the active Profile's capability list and each action's risk class before running it. File tools are confined to the project directory by a path-containment helper. The weak spot is that the project directory itself holds the Studio API keys in plaintext (.inkos/secrets.json), and the model's read tool is allowed to read any file under the project root, so the agent's own credentials are within its reach.

InkOS has a real host-side confirmation path: creating new works goes through a propose_action card that the user must click in Studio (or a slash command), and the one destructive tool (delete latest chapter) is hidden from the model entirely. But the shipped Profiles set every recoverable write to execute without asking, and the URL-fetching ingest tool is classed as an ordinary recoverable write, so outbound requests and all edits to manuscripts and story state happen unattended. The approval card shows a model-written title and summary alongside the structured payload.

The tool set is narrow by design: no shell, no generic HTTP client with methods, no SQL; tools are book-, chapter- and artifact-specific. File paths go through a containment check that is not a strict boundary. The URL ingestion tool accepts any http(s) URL with no host allowlist or block on localhost or cloud metadata addresses, which gives a hijacked agent an outbound GET channel and an SSRF primitive.

No model-reachable path executes code or shell commands. The core agent package contains no process-spawning or eval calls outside tests, and the spawn calls in the Studio and CLI packages only launch the Studio server, open a browser, build the frontend, or run the user-invoked 'inkos update' command.

InkOS reads plenty of content its user did not write: fetched web pages and PDFs, Tavily search results, uploaded files, imported chapters and canon. Nothing distinguishes that content from instructions once it is in context; tool descriptions merely say materials are 'reference only'. A hijacked session can, without any approval, read the project's stored API keys with the read tool and send them out in the query string of an ingest_material URL fetch. It cannot take destructive actions unattended, because deletion is hidden from the model and other writes are revisioned.

InkOS is built around persistent story state: truth files, summaries, materials, a retrieval index and session transcripts are written by model-driven tools and re-injected into later sessions. Work artifacts are revisioned, so poisoned state can be inspected and rolled back, and project Profile files cannot loosen the destructive-action rule. However, SKILL.md instruction files in the project's skills/ and .agents/skills folders load silently and can replace built-in skills that Profiles activate automatically, and restored transcript system messages are re-inserted into the system prompt. In CLI mode, project-scoped configuration is additionally not integrity-protected; Studio, the scored mode, is not affected.

InkOS loads no third-party code at runtime: there is no MCP client, no plugin system that runs code, and no model-file loading. Skills are plain Markdown instructions (scored under C6). The only package install is the user-run 'inkos update' command for InkOS itself.

Provider API keys entered in Studio are saved in plaintext JSON inside the project at .inkos/secrets.json, written with default file permissions. The Studio API only returns whether a key exists, which is the single masking path. There is no redaction anywhere and the model's read tool can open the secrets file, so a key can end up in model context, transcripts and outbound requests. No telemetry SDK is present.

Every tool call passes through the harness runtime, which writes an 'action-started' event with the parameters, risk class and request source to a SQLite episode ledger before the tool runs, then a completed, failed or cancelled event, plus an event whenever confirmation is required. A JSONL session transcript is kept as well. The ledger lives in the project's .inkos folder with no tamper protection, but the model has no tool that can write there.

Each LLM request has a 5-minute deadline plus stream-idle deadlines, URL fetches time out after 15-20 seconds, and the user can abort a session, which propagates an abort signal into pipeline work. There is, however, no cap on agent turns, tool calls, tokens or cost per session, so a looping agent keeps running and spending until a human stops it.