AI is finally good enough to do the work, not just describe it. The obstacle was never intelligence — it was trust. Sonaro is engineered from the ground up so that an agent working on your business can act with real power and still never hold your keys, never see another client's data, and never make a consequential change without a person saying yes. Here is exactly how.
The moment you point an AI agent at a company's real systems — its analytics, its store, its customer records — you inherit a security problem most tools quietly ignore. The standard shortcut is to hand the agent an API key and hope for the best.
That single decision is the root of nearly every AI-agent breach in the headlines: the key almost always unlocks far more than the task needs, and an agent that holds a key can be tricked into using it, leaking it, or reaching data it was never meant to touch. Sonaro is built on the opposite premise — and that premise shapes the entire system.
Everything below is an expression of these three. They aren't features we added — they are the shape of the architecture.
Credentials live in a broker the agent cannot read. The agent asks the broker to do a narrow, named thing — it never receives the secret. If the agent is ever compromised, there is no key to steal.
Each client's data, credentials, and workspace are structurally separated — not by a filter we must remember to apply, but by the architecture itself. One client's tools were never handed another's credentials.
An agent can read as much as it needs. But anything that changes the outside world — publish, create, send — is proposed, previewed, and executed only after a human approves it.
Between every AI agent and every one of your real systems sits a Broker: a small, single-purpose service we build and control. A Broker always does four things.
The Broker holds the secret for one system. The agent never receives it — and doesn't even know what it is.
Not "access to your store" — specific, named capabilities like summarize this week's traffic. Exactly what the task needs, nothing more.
Read-only means read-only at the database's own permission level — the connection is physically incapable of writing, and confidential fields are withheld even from it.
Every read, every action, every request is recorded. Nothing an agent does with your data is invisible — to us or to you.
A Broker is a receptionist who holds the keys to one filing cabinet. You can ask them to fetch a specific folder, and they'll check whether you're allowed and hand it over. You never get the keys, you can't open the other cabinets, and every request is written in the logbook.
Why one Broker per system, kept deliberately narrow. The guarantee only holds because each Broker opens onto exactly one room. A broker that could reach fifty clients by switching a parameter would reintroduce the very risk brokers exist to remove. So the multi-client system is built out of deliberately single-purpose parts — and onboarding a new client spins up their own isolated brokers, wired to their own credentials, from a reusable template. New reach is always additive and always scoped.
Content Intelligence Broker — read-only access to a client's marketing brain: search rankings, query data, AI-visibility signals, and content opportunities. It runs inside our own hardened infrastructure, reachable only over a private, authenticated channel — never exposed to the open internet.
Store Broker — reads a client's commerce data (orders, products, inventory, traffic) and offers exactly one change-the-world capability: proposing a draft article — which, being a write, is fully gated.
Social Broker — manages a client's content calendar and publishing, with per-client isolation enforced in our own code and verified in production: a client's requests can only ever reach that client's own profiles.
Every client operates inside their own sealed instance. Three properties make that real — and unspoofable.
Which client a request belongs to is derived from the credential presented — never a parameter the caller can set. This closes the single most common multi-tenant hole: asking for someone else's data by changing an ID. In Sonaro, the request has nowhere to put the wrong ID.
A client's store token, analytics access, and calendar are each held per-client and unlocked only by that client's identity. There is no master credential spanning clients — onboarding provisions their secrets, isolated by construction.
The working state an agent builds while helping a client — a draft, a queued action, an in-progress report — lives in a database attached to that work, not a shared pool. Sealed, durable across restarts, and out of view the moment the boundary says so.
This is what makes Sonaro a genuine multi-client platform rather than one tool with a client dropdown. The isolation isn't a rule we uphold — it's a wall we can't accidentally walk through.
Reading is one thing. Changing the outside world is another — and Sonaro treats it that way. Every action that would alter a real system runs the same disciplined flow.
The agent doesn't act. It submits a proposed action, with the exact change spelled out.
The platform produces a preview of what would happen and hands the agent a stand-in result, so it keeps working without blocking on a human. Nothing has actually changed yet.
A person reviews the proposed action — with the real payload visible — and approves or rejects. Pending actions can be cleared in bulk, so oversight never becomes a bottleneck.
Only on approval does the single, real change execute — exactly once, with safeguards that make a duplicate impossible even under retries.
Actions are built to be undoable wherever the underlying system allows it.
This solves the trap every AI-action tool falls into: either you approve every step by hand and the agent stalls constantly, or you turn approvals off and pray. Sonaro's gate splits the difference — the agent keeps moving on a simulated result, and the real, irreversible action waits for a human.
On top of the gate sit hard rules for anything an AI writes: strict allowlists on what fields it can set, dangerous defaults forced to the safe value on our side, aggressive sanitization of AI-authored content, and tight limits on any destination an action can reach. We assume the AI's output is untrusted and validate it accordingly — because that is the only safe assumption.
A client doesn't touch brokers and gates directly. They work in a single place where they — or an AI agent acting on their behalf — can ask for what they need in plain language. The platform routes the request through the right Broker, under the right client identity, past the approval gate when required, and returns a result.
The tools inside that workspace — a store-performance pulse, a content-opportunity explorer, a blog drafter — are each wired only to the brokers they need. And they're built from reusable templates that carry the capability, but none of any client's data or credentials. When we bring on a new client, we spin their workspace up from those templates and bind it to their identity and their secrets at setup. The template carries the shape; the client binding carries the secret. That's what lets us productize a capability once and deploy it — safely isolated — for every client, instead of hand-wiring a fragile integration per client.
None of this is the "connect an API key and go" path most AI tools take. Making an agent safe to point at real business systems meant designing, from the ground up:
We built Sonaro on foundations whose security has been stress-tested at enormous scale — a deliberate choice, so the hardest and most dangerous primitives rest on ground that has already been hardened by others' expertise, then layered with our own guarantees on top. The result is an architecture a business can hand real access to and trust what happens next.
Sonaro lets AI act on your real business data — because the agent never holds your keys, never sees another client's data, and can never make a consequential change without a person's approval.
Sonaro is opening to a first cohort of brands. Tell us what you're trying to grow — we'll show you the signal in your own data, safely.