Enterprise grade security, built in
Keep your data safe while you move faster. Every agent is scoped to what it's allowed to do, every run is logged, and risky actions wait for a human.
Your data is never used to train any models.
How agents work safely
Every agent runs inside guardrails that limit what it can use, what it can send, and when it needs a human.
Even if an agent is misled by something it reads into trying an instruction it shouldn't follow (what's known as prompt injection), its guardrails hold anyway. It still cannot use a tool outside its allowlist, send an argument outside its restrictions, or take an action without the approval it requires.
Tools are allowlisted per agent
Theona automatically sets a guardrail on which tools an agent can use, granting access to only what the task actually needs. You can also set that list by hand, and you can lock limits at the workspace level that apply to every agent in it.
Theona assigns this list automatically based on what the agent does. You can edit it yourself, and workspace level limits apply on top.
Guardrails on tool arguments
Theona also sets a guardrail on what an agent can pass to a tool, automatically restricting arguments to the values its task requires: exact values, wildcard patterns, or both. You can tighten these further yourself. An agent cannot call a tool with an argument outside its allowed values, the call is blocked before it leaves our perimeter.
A call outside those values never executes. It is blocked by the guardrail before it reaches the tool.
Access is inherited, never granted
An agent works through the connection of the person who set it up. Revoke their access and the agent loses it too.
Revoke the person's access and the agent loses it in the same moment.
Approval before sensitive actions
Reads and reversible edits run on their own. Anything that leaves your workspace or can't be undone waits for a person.
Reads and reversible edits run on their own. Anything that leaves your workspace or can't be undone waits for a person.
Additional safeguards
Secrets the model never sees
An agent refers to a secret by name only. The value is filled in on our side at call time, so it never reaches the model or the transcript.
Tool calls are sandboxed
A tool call can only reach the exact endpoint it was built for, nothing else on the network, and any result is checked before it's returned to the agent.
Agent chosen URLs are checked
Where an agent picks the address to fetch, the request is checked before it goes out: http and https only, never a private or internal address, with limits on redirects, time, and response size.
Inbound triggers are verified
A webhook is how an agent gets started, so every inbound trigger is signature checked against the raw request before anything runs.
Every run and every tool call is recorded, and you can open and read it yourself
Each run shows you what the agent decided, which tools it called, with which arguments, and what came back; none of this is logged only on our side, out of your view.
Change history on every agent
Instructions, tools, and restrictions are versioned. See what an agent looked like at any point, and roll it back.
How we protect your data
Encryption by default
TLS in transit and strong encryption at rest. Integration credentials and stored secrets are encrypted with AES 256 GCM.
Least privilege access
Role based controls, with least privilege as the default. Every query is scoped to the signed in user, and row level security in the database sits behind that as a second line.
Monitored and tested
Continuous monitoring, internal reviews, and regular security testing.
Resilient by design
Isolated production, routine backups, and tested recovery procedures.
Logs that don't carry your data
Logs and error reports pass through one redaction layer that strips credentials and personal data. Background jobs carry record IDs only, never message content.
Your data is never used to train any models
Customer data is never used to train any model, ours or a third party's.
On premise deployment
An Enterprise add on for teams that need the entire loop closed inside their own perimeter.
Deploy Theona in your own infrastructure and connect your own model providers. Nothing leaves your environment: not the data agents work with, not the calls they make, not the models they run on.
Talk to us about on premiseTheona
agents and runtime
Your models
your providers
Your data, your network, your logs
Policies and processes
Data management
Classification, protection, retention, and deletion aligned to business and legal needs.
Access control
Role separation, least privilege by default, and periodic access reviews.
Incident response
Preparedness, detection, escalation, and post incident reviews with playbooks.
Vulnerability management
Routine patching and remediation with risk based prioritization and tracking.
Vendor risk
Security evaluation of critical third party providers and ongoing oversight.
Compliance
SOC 2 Type II
Audit in progressOur SOC 2 Type II controls are already being met, and the audit is currently in progress. The control list and the audit engagement letter are public in ourTrust Center.
Open Trust Center →GDPR
CompliantA signable DPA, a publishedsub processor list, consent records with full history, and self serve export of your data as a single archive. Error reports are dropped for users who have not consented to them. Deleting an account erases its content permanently after a 30 day grace period; financial records are anonymized rather than removed, because tax law requires keeping them.
We align our controls to the Trust Services Criteria and build the evidence required for independent assessment.
Security FAQ
Which actions can the agent take autonomously versus with human approval?
Every agent has a closed list of tools it is allowed to call; anything outside that list is technically impossible for it to do. Sensitive or irreversible actions, such as sending, deleting, purchasing, or running code, always wait for a human approval, no matter which agent is running.
Can approval be required per action type, such as sending, deleting, purchasing, or code execution?
Yes. Approval gates are set per tool and per argument, so you can require a human sign off for one action type while letting another run automatically.
How do you log the decision process behind an autonomous action, not just the final output?
Every run stores the full chain: what the agent decided, which tools it called, with which arguments, and what came back, not only the final result.
Can you reconstruct what an autonomous workflow did in a given time window?
Yes. Run history combined with versioned agent configuration lets you see exactly what an agent looked like and did at any point in time.
Is there a kill switch to halt all autonomous activity?
Revoking access to the connections an agent uses stops every agent built on those connections immediately. This kill switch is triggered by you, not only by us.
Are tool calls sandboxed?
Yes. Every tool call runs in an isolated execution path that can only reach the exact endpoint it was built for, with no access to anything else on the network.
Is our data used to train your models?
No, never. We also have agreements in place with our LLM providers stating that they do not train on the data we send them either.
Report a vulnerability
Found a security issue? We welcome reports from researchers and will work with you to resolve confirmed vulnerabilities. Emailsecurity@theona.aiand review our coordinated disclosure policy before testing.
Read our Vulnerability Disclosure PolicyBuilt for trust, improving every day
We regularly review controls, invest in monitoring and automation, and share updates as we grow.
Disclaimer: This page is for informational purposes only and does not create any legal obligations, warranties, or commitments.