Security starts with clear boundaries.

Credentials and connected tools

Saved credential values are encrypted with authenticated AES-GCM envelopes in a separate credentials service. The Gateway resolves only the credentials needed for a request under an actor and capability context. It passes them to the trusted runtime or connector separately from model conversation and tool-call arguments. A connector needs the credential to authenticate; a connector you do not trust could return sensitive data in its output. Review connector provenance and permissions.

For built-in Gmail and Microsoft 365 mail, you sign in with the provider. Refresh credentials and signing keys stay in the credentials service; the connector receives the access token needed for a mail call. Sending is initially configured as Ask; review the current policy for each agent, because that choice can be changed.

Local and cloud models

The Kautuka appliance runs agent execution. You can configure a local model or a cloud model provider. When using a cloud provider, the prompt and selected context sent for that call leave the appliance and are handled under that provider’s terms. A local appliance does not mean every model is local.

Container isolation

Agents run in memory inside the Gateway and have no shell or file access of their own. Shell commands, skill scripts and local connectors run in rootless Podman containers as a non-root user. Container configurations drop all Linux capabilities, prevent privilege escalation, use a read-only root filesystem, and apply process and resource limits. In the agent’s sandbox, only the agent’s workspace is writable. Skills always run in the agent’s own sandbox, never on the host.

The sandbox is set per agent and can be switched off. An agent without a sandbox is not offered shell commands or skills. Each local connector runs in its own container by default, or can share the agent’s sandbox. For a connector in its own container, you choose whether it can read the agent’s files.

Actions set to Ask wait in the Gateway for a decision and are not sent to the container manager until they are approved. Model API keys stay with the Gateway and never go inside a container; a connector or skill receives only the credentials it is set up to use. Containers have network access. Remote HTTP connectors run on the provider’s side: the Gateway calls them over HTTPS, and nothing for them is installed on your appliance.

Approvals and history

Approval rules can be configured for connectors and functions, skills, shell commands, or delegated agents. A requested approval is a decision point, not a blanket rule that every action will always pause. The persisted operational history records events such as tool calls, approval decisions, run relationships, and workflow routes.

History is useful for reviewing operations, but it is not a tamper-proof compliance archive. It does not expose private model reasoning or prove every external side effect occurred exactly once. Workflows and approval continuations have recovery support; arbitrary interrupted external actions are not guaranteed safe to repeat.

Personal and shared agents

Conversations and approvals are user-owned, with administrative access available where configured. Agents, connectors, and skills can be set up for one user or for the whole system. Agent files live in Kautuka’s own protected storage, with separate access controls; they are not kept in your normal folders. Sharing a system agent gives each person the same configuration and tools, but not the same working context: each person’s files and remembered facts remain scoped to them. User-owned objects use owner-scoped access, with administrative fallback on some operations. Choose separate agents when people need separate tools or configuration.

Other implementation boundaries

• The Gateway listens on loopback by default; exposing it changes the threat boundary.
• Agent files are stored in Kautuka’s protected storage and access is controlled separately from your normal folders.
• Container network access permits outbound connections; isolation is not offline execution.
• Release signatures and trust policy are checked by the installer/update path; use the published signed release manifest.