AI 代理安全
AgentJail 1.7 Makes Agent Permissions Session-Bound, Single-Use Grants; Host Connectors Deny Forwarding by Default
AgentJail 1.7.0 manages file, command, network, MCP, and credential permissions through a typed lifecycle, requiring grants to complete activation and auditing before use. The release also introduces trusted host connectors, while production MCP forwarding remains fail-closed to prevent data paths from opening before they are bound to native approval evidence.

AgentJail 1.7.0 upgrades temporary permissions for coding agents from simple allow/deny decisions to precise, non-transferable runtime grants. Each grant is bound to an agent, user principal, session, action, normalized resource and parameters, policy version, scope, expiration time, and consumption status. It proceeds through states including requested, approved, active, consumed, expired, and revoked. An explicit deny still takes precedence over a grant, and approval does not make a permission immediately usable: if connector startup or a readiness probe fails, the permission does not become active.
This separation addresses a common timing-gap problem in agent security: after a user approves an operation, the session, policy, or target resource may have changed. The new release requires approval and activation records to be durably persisted before exposing a permission to the agent, and it now enforces denial precisely at the expiration boundary. It also serializes connector activation and revocation, revokes broker routes before cleaning up sessions, and rejects Linux runtime roots and sockets that are symbolic links or have incorrect ownership or permissions.
Host connectors can now be predefined by trusted global policy, such as a fixed local Chrome CDP endpoint. Agents inside the sandbox may reference only a connector ID and cannot specify a host or port themselves. Diagnostic tools report grants, authorization, activation, transport, and upstream capabilities separately without disclosing approval evidence. Notably, production MCP forwarding is not yet enabled: the project will remain fail-closed until native approval evidence and a grant-aware data plane are complete.
Deployers still cannot treat command hooks as a security boundary. The official documentation explicitly states that the PreToolUse hook is a cooperative interception mechanism; variable expansion, `eval`, or other interpreters may bypass string-based policies. Sensitive environments must still use Landlock, macOS Seatbelt, or containers. Windows also currently lacks an equivalent native sandbox, while CI does not yet have an official Action or image. Engineering teams should next validate grant revocation, retries, and audit-failure paths instead of testing only the successful approval flow.