Security
Security at Charla: autonomy with brakes
How Charla keeps agentic assistants under control: per-assistant isolation, multi-factor access, a tamper-proof audit log, and human oversight before every change.
An agentic assistant does more than chat: it queries knowledge bases, calls tools, and takes actions in real systems. The greater the autonomy, the more the brakes matter. Charla's security is designed so each assistant can do a lot, without ever doing what it shouldn't. The practices described here are engineering controls we apply in the product, not formal certifications.
Each assistant is an island
The first barrier is isolation. Each Charla assistant has its own knowledge base and its own access list. One assistant's knowledge and the permissions it is granted never leak to another. In practice, that means separating departments, brands, or customers is the default, not an extra setting:
- Dedicated knowledge base per assistant: documents, data, and context stay contained within the assistant they belong to.
- Its own access list per assistant: what an assistant can reach is decided individually, with no implicit inheritance.
- No cross-leakage: one assistant's knowledge and permissions never become visible to another.
Who gets in, and how far they go
Access is governed by role-based access control (RBAC), with hierarchical, scoped permissions: each person gets exactly the reach they need and nothing more. On top of that, we reinforce the identity of whoever signs in:
- Multi-factor authentication (MFA) via TOTP, so a password alone is never enough.
- Strong password hashing: credentials are never stored in plain text.
- Short-lived sessions that rotate, shrinking the useful window of any improper access.
Everything is recorded, and nothing can be erased
Every privileged action and every tool call is written to an append-only audit log: rows are only ever added, never altered or deleted. The result is full accountability: you can always reconstruct who did what, when, and through which tool, with no room to rewrite history after the fact.
Secrets stay sealed
Assistants that connect to external tools need credentials, and those credentials are the most sensitive asset of all. At Charla they never travel loose:
- Credentials are encrypted and held in a dedicated secret manager.
- Credentials for external tool connections are sealed with strong encryption.
Connections to the outside world, under guard
When an assistant calls an external tool, Charla controls where the request is allowed to go. Outbound connections are egress-guarded: requests aimed at internal or private networks are blocked, a defense against SSRF (server-side request forgery). All traffic is encrypted in transit (TLS), end to end.
The assistant never shows its backstage
Charla never exposes its own raw internal reasoning in responses. The user receives the useful conclusion, not the raw chain of thought that produced it, which reduces the surface for extracting instructions, prompts, or clues about how the system decides internally.
Changes go through people
Autonomy is not a blank check. Knowledge and configuration changes follow a propose-then-approve model: a change is proposed and only goes live after a person approves it. There is also an optional scope gate that lets the assistant refuse requests outside its domain.
The more an agent can do, the more it matters who approves what. We keep a person in command of the changes that carry weight.Charla design principle
Aligned with the spirit of SAIF
Our controls speak to the spirit of Google's Secure AI Framework (SAIF) and its three agent controls: user approval, least-privilege permissions, and observability. Approval shows up in our propose-then-approve flow; least privilege, in scoped role-based permissions and per-assistant isolation; observability, in the tamper-proof audit log. This is alignment of practice, not certification.
To be clear: everything described here consists of engineering security practices we apply in the product, not formal compliance certifications. Charla does not currently hold a formal compliance certification, and nothing on this page should be read as such. The goal is to show, transparently, how we build autonomy with brakes.