The Model Decides. The Runtime Allows.
An autonomous agent is not a chatbot. It has files, a shell, a network connection and, in many setups, a messaging channel that other people can reach. Once strangers can message the agent that holds those tools, the question stops being what the model will say and becomes what it is allowed to do.
Palaka Lite is my attempt at a smaller answer to that. It is a Rust-native agent harness: tool execution, memory, tasks, permissions, multiple LLM providers, and remote channels such as WhatsApp and Telegram, all on one shared core runtime. The README says I started it in early 2026 after using autonomous agents like OpenClaw, and that setup complexity, ever-growing context and permission management were the problems I kept running into.
Two roles, deny by default
Every incoming request is associated with a role. There are two. The owner is the agent's owner and explicitly trusted users. External is everyone else: customers, leads, public users. External access is deny by default, and a role alone grants nothing. A permission has to name the operation.
Permissions are scoped three ways. Tools: what the agent may execute. Directories: which parts of the filesystem it may touch. Channels: where the agent can be reached and by whom. Identity, permissions and tool access are kept as separate boundaries instead of one switch labeled trusted.
Why the check lives in the runtime
The README states the design in one sentence: the model decides what to do, the permission layer decides what it is allowed to do. If an external user attempts a prompt injection, the model may still generate the request. The runtime permission layer blocks the corresponding tool execution. The model does not get to grant itself more privileges.
That is a narrow claim and a useful one. It does not say the model cannot be fooled. It says being fooled is not enough, because the enforcement point is code that does not read the conversation. A system prompt that says never run shell commands for strangers is a request. A policy check that refuses the shell call is a boundary.
Where it sits in the code
Palaka Lite is a Cargo workspace. The backend runtime is split into crates: palaka-session for the agent loop, HTTP and tool dispatch; palaka-context for token tracking and compaction; palaka-tools for the registry (filesystem, shell, web, memory, todo); palaka-policy for owner versus external gating; plus providers, config, events, terminal and channels. The Tauri v2 desktop GUI and the Ratatui terminal UI both sit on the palaka-rs facade crate, and the repo also contains a VS Code extension with a bridge.
The README's architecture diagram draws the session crate calling the policy crate, which is the point: tool dispatch passes through the permission check on its way to executing.
What this does not claim
I have not published a benchmark or a third-party security review of Palaka Lite, and this article does not offer one. The repository is public under AGPL-3.0, created on August 22, 2026. A deny-by-default policy is only as good as the permissions written into it, and an owner who grants too much has granted too much. What the design buys is a place to look: when something runs that should not have, there is one layer to audit.