AI agent security: permissions, audit, sandboxing

A chatbot returns text. An agent takes actions. When an agent runs on your desktop, “take an action” can mean deleting a file, sending an email, running a shell command, or paying an invoice. That changes the security question from “can the model say something wrong?” to “what is the worst thing this software can do before I notice?”

Three concrete failure modes drive the design of any serious agent.

• Prompt injection. The agent reads content: a webpage, a PDF, an email, the output of a shell command, and that content contains hidden instructions. OWASP ranks this as the number-one risk for LLM applications in 2025, splitting it into direct (user types something hostile) and indirect (the model reads something hostile embedded in benign content) (OWASP LLM Top 10, 2025). The model cannot reliably tell the two apart.
• Excessive agency. An agent handed sweeping tool access, then left to run in a loop, will eventually do something its operator did not intend. OWASP's mitigation is blunt: scope tools to the minimum needed and require human approval for privileged operations.
• Tool-level vulnerabilities. In May 2026, Microsoft published research showing that two vulnerabilities in the Semantic Kernel agent framework let a successful prompt injection escalate into remote code execution on the host. Microsoft's framing: “AI models aren't security boundaries. The tools you expose define your attacker's affected scope.”

Read those three together. The threat is not that the model goes rogue. The threat is that the model receives bad instructions from data it processes, has too many tools wired up, and one of those tools has a bug. A permission system has to defend against all three. The permission tiers below turn those risks into explicit execution rules.

Least privilege means giving an agent only the tools, folders, applications, and time window required for the current task. Static scope sets the outer boundary before a task starts; runtime approval decides whether a consequential action inside that boundary may happen now. A folder grant should not imply permission to delete its contents, and permission to draft an email should not imply permission to send it.

In practice, start read-only, elevate one capability at a time, prefer approvals that expire with the session, and revoke them when the job is complete. This limits the blast radius of a bad instruction without making ordinary work impossible.

The NIST AI Risk Management Framework organises AI risk work into four functions: Govern, Map, Measure, Manage. Translated to a desktop AI agent, the practical question is: which actions does the agent perform freely, and which require an explicit human check? LapuAI uses four tiers.

Two consequences fall out of this design. First, scope matters more than tier. A file write is reversible inside a project workspace and catastrophic outside it. NVIDIA's AI Red Team explicitly recommends blocking writes outside the workspace to prevent “persistence mechanisms, sandbox escapes, and remote code execution techniques.” Second, approvals are not cached. If the agent earned permission to delete one file an hour ago, that is not a license to delete a different file now.

Every action LapuAI takes is recorded as a row in a local audit log. The log answers four questions for any past action: what happened, when, on what input, and why the agent did it. Concretely each row captures:

• Timestamp. ISO 8601, local timezone.
• Action type. One of file:read, file:write, file:delete, shell:run, net:fetch, app:control.
• Arguments. Full file path, full shell command, destination URL. No truncation.
• Triggering prompt. The user instruction (or up-stream agent step) that led to this action.
• Outcome. Succeeded, rejected by user, errored, or cancelled.

Logs are stored on your machine. Default retention is 90 days, configurable. Logs never leave your machine in the Free, Premium, Pro, and Max tiers. Teams and Enterprise plans can export to a customer-managed sink (SIEM, S3, GCS), for longer retention required by compliance regimes.

LapuAI runs as a desktop application, not a kernel module. The permission system enforces what the agent can do at the application layer; the operating system enforces the rest. The honest split looks like this.

What LapuAI contains. Process isolation between the renderer, the agent loop, and the tool executors. The agent cannot bypass its own permission checks to call a tool the user has not approved. Shell commands run in a subprocess that the agent cannot replace at runtime. File operations resolve symlinks before checking workspace boundaries, so a symlink trick cannot escape the workspace.

What the OS contains. macOS System Integrity Protection blocks writes to system folders even if LapuAI is compromised. Windows User Account Control blocks privilege elevation. App sandbox entitlements scope what files LapuAI can see at all. These are the real backstops if the agent layer is bypassed.

What no software can contain. A determined prompt injection attack delivered through hostile content the user instructed the agent to process. LapuAI cannot fully prevent this. It can only contain blast radius through per-action approvals, workspace boundaries, and the audit trail. Anyone who tells you their agent is “immune to prompt injection” is selling marketing.

Different agents make different bets about where to draw the security boundary. Each has trade-offs.

These are not all the same product. A remote browser agent and a desktop file-and-shell agent solve different problems with different threat models. The right comparison is not “which is safest” in the abstract: it is which security design matches the work you need an agent to do. If you want a head-to-head on the browser-agent flavour, see LapuAI vs OpenAI Operator.

The same permission and audit machinery that protects an individual user also covers the compliance ask from a security review. Two angles matter for buyers.

Audit trail as a compliance artefact. Every action an agent took on a regulated workstation can be reconstructed from the local audit log. On Teams and Enterprise plans, logs can be shipped to a customer-managed sink for retention periods longer than 90 days: SOC 2 evidence collection, HIPAA access logging, internal forensics. The audit format is documented and stable.

Identity and access. Teams and Enterprise plans support SSO and SAML, so the agent inherits the identity boundary the rest of the workstation already enforces. Combined with the workspace boundary, this scopes what the agent can touch to what the user is already authorised to touch. See pricing for the full Teams and Enterprise feature set, and desktop workflows by role for the operations-team view.