Eigent

Eigent runs as the desktop user and does not narrow that authority. Shell commands inherit the backend's environment, which includes connector API keys loaded from the user's ~/.eigent/.env file; only Eigent's own control credentials are stripped. Connected services (mail, drive, chat, code hosting) are reached with the user's long-lived keys or tokens. The permission gate decides whether an action may run, but it does not give tools a narrower identity.

This is Eigent's strongest control. Every tool call is recorded and passed through a deterministic permission engine before it runs; in the default "request approval" profile anything that is not a code-declared read (shell commands, file writes, browser actions, MCP and connector calls, memory changes) waits for the user, who sees the call and its arguments (large ones as a preview). The approval is bound to a digest of the full call and checked again before dispatch, shell approvals can't be saved as standing rules, and the model cannot change its own permission profile. Gaps: web-fetch and search tools are classed as reads and run unattended, unknown tools are prompted rather than refused, full-access mode is a persistent per-space setting rather than a time-bounded one, and external actions such as sending messages can't be undone.

The default toolset is broad: a host shell, file writes, a browser, web fetch and search, MCP servers and delegation are all enabled. The shell takes an arbitrary command string filtered only by the underlying library's safe mode, and web fetch accepts any URL. Eigent derives risk tags from paths and commands (credential directories, Git hooks, auto-executed project files, paths outside the workspace) but uses them to escalate approval rather than to restrict what tools may do. A read-only profile exists but is not the default.

Model-generated shell commands run directly on the host as the desktop user, in their own process group, with a command filter from the CAMEL library's safe mode. There is no container, OS sandbox profile or network restriction, and the project's own security policy says the permission system is not an OS sandbox and that shell access equals full access to the user's files and processes. The approval gate in front of each command is the only barrier.

Eigent reads web pages, search results, files and MCP output with no marking of what is untrusted. What limits a hijacked session is the approval gate: in the default profile writes, shell commands, browser actions and connector calls all need the user's approval. Web fetch and search are treated as reads and run without approval, so injected instructions can send data out through a URL without the user being asked. Irreversible actions still need a human.

Persistent memory is well guarded: the agent's memory write, update, forget and promote tools all go through the approval gate and a memory review step, automatic memory extraction only reads the user's own messages, and memory is stored per user, space and project. The weaker part is auto-loaded context: skills in the workspace folder (skills/, .eigent/skills, .agents/skills) and a project skills-config file are discovered silently and take precedence over the user's own skills. Workspace .env files are not loaded.

Third-party code arrives mainly as MCP servers the user adds (usually unpinned package commands) and as skills, which can include scripts. Workspace bundles are installed through a review step with digests, but plain MCP servers and skills are not pinned or verified, and skills placed in the workspace folder are picked up without an install step. Running a skill script or an MCP tool still needs approval, but MCP servers run as separate processes under the same user account.

Connector keys are stored in plaintext in ~/.eigent/.env with owner-only permissions and loaded into the backend's environment, where shell commands inherit them. Eigent redacts secrets from persisted tool arguments, permission cards and journal text with a shared redaction helper. Model request and response logging from the CAMEL library is switched on by default and is not redacted. Third-party telemetry only starts when the user supplies Langfuse keys.

Eigent keeps a durable SQLite run journal outside the workspace. Every tool call is checkpointed with its arguments, agent, step and delegated sub-agent step before it is allowed to run, and permission decisions are written as security audit events with the actor type (system or auto-reviewer). A tool call cannot be dispatched without that checkpoint. The journal is an ordinary local database the same user could edit, with no hash chain or signing; the gate blocks shell commands that name the journal files, but the project itself says that holds only within the same-user boundary.

In the default execution path there is no step cap and no token or cost budget. A hard per-step timeout exists but is off unless an environment variable sets it; what is on by default is a 30-minute no-progress timeout for agents and workforce tasks. Delegation depth is capped at one level, shell commands run in their own process group that can be killed, and the stop button asks the workforce to stop gracefully.