Eino

Eino's core library holds no credentials of its own and has no identity or authorization layer: every tool a developer registers runs as an ordinary Go function inside the host process, with whatever API keys, cloud credentials, and file access that process has. Nothing in the framework scopes a tool to a narrower identity or checks, per call, whether the requesting user may perform the action. The only mention of authorization is a line in the DeepAgent system prompt, which is not an enforcement mechanism. How much a hijacked agent can do is therefore decided entirely by the tools the developer wires in.

Eino ships no approval gate. When the model emits a tool call, ToolsNode runs it immediately (in parallel with any other calls), including the built-in shell 'execute', 'write_file', and 'edit_file' tools. The framework does provide an interrupt/resume primitive that a tool can call to pause and wait for a human, and the paused call resumes with the same arguments, but each developer must write that check into each tool themselves; nothing is gated by default. A wrongly executed action has no framework-level undo.

The framework's validation layer is thin. Tools built with its InferTool helper get their JSON arguments decoded into a Go struct, which rejects wrong types, and calls to tools the agent wasn't given are rejected by default; but schema constraints such as required fields, enums, or numeric bounds are not enforced, and tools implemented directly receive the raw argument string. The built-in 'execute' tool passes an arbitrary shell command straight through, and the filesystem middleware enables write, edit, and execute tools by default whenever a backend and shell are supplied. Jinja prompt templates have file-inclusion keywords disabled, a small but real hardening.

Eino exposes a first-class 'execute' tool that sends whatever command the model writes to a developer-supplied Shell implementation, with no isolation of its own: the core repo contains no sandbox, container, or process-separation code. Worse, the tool description the framework shows the model claims 'Commands run in an isolated sandbox environment', which is true only if the developer's Shell happens to provide one. Isolation is therefore entirely the integrator's responsibility, and with a local shell a hijacked agent runs commands as the host user.

Tool results, including web or file content, enter the conversation as ordinary tool messages with no provenance tag, and nothing in the framework changes what the agent may do after it has read untrusted content. Content loaded by the AGENTS.md middleware is injected as a user message, giving file content the same standing as the principal's own request. Because the documented DeepAgent setup combines web search, shell, and Python tools in one session with no gate, a successful prompt injection can both exfiltrate data and take irreversible actions unattended.

Core Eino has no long-term memory module, but it ships two auto-load paths: the AGENTS.md middleware silently injects configured instruction files (and anything they @import) into every run as a user message, and the skill middleware rescans a skills directory and offers every SKILL.md it finds. Neither validates content, and import resolution in the AGENTS.md loader is not confined. If these point into the same backend that the agent's write_file tool can modify, an injection can write itself into instructions that load in every later session; nothing in the framework prevents that loop.

Eino's skill middleware is its extension mechanism: it rescans a directory for skill folders, offers each one to the model, and its system prompt tells the model that skills may contain Python scripts or other executables and to run them with absolute paths. Skills are not pinned, hashed, or individually approved; dropping a folder into the skills directory enables it on the next run. Any script a skill ships runs through the same unsandboxed execute tool with the agent's full authority. The core repo has no MCP client or plugin loader.

The core framework stores no credentials, sends no telemetry, and only logs error values in a few retry/failover paths, so it adds little exposure of its own. But it also has no secret-handling primitives: there is no redaction before callbacks, logs, checkpoints, or model-bound messages, and tool output (including anything a shell tool prints) flows to the model provider unfiltered. Import resolution in the AGENTS.md loader is also not confined, which affects what reaches model context.

By default Eino records nothing: the Runner emits a stream of agent events (model messages, tool results, agent name and run path) to the calling application, which may log or discard them, and sub-agent internal events are not forwarded unless enabled. A callback system can observe the start, end, and errors of every component including tools and is propagated to sub-agents, but it is opt-in, records no approvals, and handler failures are silent. Any durable audit trail must be built by the integrator.

ChatModelAgent stops after 20 model calls by default, which bounds a single agent loop, and a cancel API can stop a run at safe points or immediately. There is no wall-clock limit, no per-tool timeout, and no token or cost budget; tool calls in one turn run in parallel without a concurrency cap; and each sub-agent or agent-tool starts with its own fresh 20-iteration budget. The LoopAgent workflow defaults to unlimited iterations. Immediate cancel stops the graph waiting, but Go tool goroutines that ignore context cancellation keep running.