Security for autonomous AI agents
Encrypted by default. Never used to train AI models.
Abundly agents are autonomous by design, with the controls to make autonomy safe at scale. Code-enforced guardrails, human approval, role-based access, encrypted credentials, audit trails, and EU data residency let you give agents real work to do, with confidence.
Trusted by leading organizations
A multi-layer architecture, four layers of defense
Security is provided through four layers that build on each other. Each one closes gaps the next cannot. The first three are always on, the fourth is yours to configure.
Platform layer
The Abundly platform is the foundation. It enforces guardrails, screens untrusted input, runs access checks, and isolates everything that runs on top.
- Internal system prompt tuned to make any LLM behave as a responsible autonomous agent
- Attack detection screens untrusted trigger content before the agent acts on it
- Guardrails enforced by code: whitelists, allow-lists, and limits checked by the platform, not by the agent
- Role-based access control over agents, capabilities, and agent-to-agent communication
Agent layer
Each agent is limited to its instructions and the capabilities you enable. An agent without email access cannot send emails, no matter what it is asked to do.
- Capabilities are explicit and opt-in per agent
- Instructions, documents, and connected APIs are scoped to that agent
- Agents are isolated by default; they only see each other if you configure it
LLM layer
The model the agent reasons with. Abundly uses Claude from Anthropic by default (an industry leader in AI safety), with OpenAI, Google, and other models selectable per agent. The model is one component, not the only one.
- Default: Claude with Constitutional AI training and pre-release safety evaluations
- Red-teaming with external partners including the US and UK AI Safety Institutes
- Workspace admins can control which models are available to users and agents
- Models are interchangeable, so safety does not depend on any single vendor
User & process layer
This is where you live. You decide which capabilities each agent gets, configure guardrails, require approval for sensitive actions, and review what agents do. The platform provides the controls. You set the policy. Abundly supports users through training, onboarding, and ongoing guidance, so people are equipped before they handle sensitive data.
- Choose autonomy level per agent, from "ask before every action" to fully autonomous
- Approve or reject high-stakes actions inline in chat or from the Activity page
- Review the diary and activity log to see exactly what each agent has been doing
Always on — the platform, agent, and LLM layers are built in.
Your part — configure capabilities, guardrails, approvals, and oversight to match your risk profile.
Built-in security features
Each feature below is configurable per agent and per capability. Start restrictive, then relax as the agent earns trust.
Attack detection
Automated screening of untrusted trigger content (incoming emails and SMS) for prompt injection, data exfiltration, jailbreak, and reconnaissance attempts. Runs in a separate context before the agent acts, so suspected manipulation is flagged before it reaches the agent.
How attack detection worksGuardrails
Technical constraints enforced by platform code, not LLM reasoning. Email allow-lists, SMS and phone restrictions, optional approval on HTTP requests. The check runs in platform code before the action executes, so it does not depend on what the model decides.
Configure guardrailsUser approval
Put a human checkpoint before sensitive actions. Pending requests appear inline in chat and on the Activity page. Owners get in-app notifications (and optional email) for approvals created by background triggers, so nothing gets missed.
How approvals workAccess control
Role-based permissions across workspace, team, and per-agent settings. Four access levels (Owner, Edit, Use, Nothing), private and admin-restricted agents, and explicit controls for agent-to-agent communication.
Set up access controlCredential security
Encrypted storage of secrets and API keys, with decryption keys stored separately. Credentials are never included in prompts or visible to the LLM. The platform injects authentication after the model has generated the request.
Credential patternsAudit trails
Every agent action is logged with timestamp, actor, trigger, plan, execution, and result. Logs are immutable. View activity in real time, or read the agent diary for a high-level summary.
Activity monitoringWorkspace governance
Workspace admins can disable capabilities platform-wide, block custom MCP servers, control which models are available to users and agents, and configure attack-detection alert recipients. Team admins can layer further restrictions on top.
Agent managementPlatform-level guardrails
Guardrails enforced by the platform
Telling an agent "do not email external domains" in its instructions is helpful, but not foolproof. LLMs can be tricked, confused, or make mistakes. Guardrails are checks that happen at the platform level before the action executes, whatever the instructions say.
| Setting | Options | What it does |
|---|---|---|
| Restrict who the agent can email | Off, or on with an allow-list of addresses and/or domains | Hard limit on who the agent is allowed to contact |
| Inside the allowed list | Send the email, or ask for your approval | How the agent behaves for recipients you trust |
| Outside the allowed list | Block the email, or ask for your approval | How the agent behaves for anyone else |
| SMS and phone calls | Same allow-list plus inside/outside-list approval model | Consistent guardrail pattern across outbound channels |
| HTTP requests | Optional approval per request | Add a human checkpoint to any custom API the agent can call |
Restrict who the agent can email
Options
Off, or on with an allow-list of addresses and/or domains
What it does
Hard limit on who the agent is allowed to contact
Inside the allowed list
Options
Send the email, or ask for your approval
What it does
How the agent behaves for recipients you trust
Outside the allowed list
Options
Block the email, or ask for your approval
What it does
How the agent behaves for anyone else
SMS and phone calls
Options
Same allow-list plus inside/outside-list approval model
What it does
Consistent guardrail pattern across outbound channels
HTTP requests
Options
Optional approval per request
What it does
Add a human checkpoint to any custom API the agent can call
A typical setup: restrict recipients on, "send inside" the allow-list, "ask outside". The agent works freely with known contacts; you review anything new.
Workspace-wide policies, such as which capabilities and models agents may use and how much they may spend, are set by admins.
See governanceDedicated deployment for enterprise
For organisations that need to be separated from other tenants, Abundly offers dedicated infrastructure. Your own database and your own agent service, isolated from the shared multi-tenant infrastructure.
Dedicated database
A separate database instance for your data, isolated at the infrastructure level from other customers.
Dedicated agent service
A single-tenant agent runtime, so your agents do not share execution infrastructure with other organisations.
Same EU residency
Hosted in EU data centers just like the shared platform. Same encryption standards. Same audit trail. Same security features. Just on dedicated infrastructure.
Dedicated deployment is part of the Enterprise plan. Talk to us to scope it for your organisation.
Infrastructure & compliance
Abundly is built on enterprise-grade cloud infrastructure with security and compliance at its foundation. All customer data is stored in the EU, encrypted at rest and in transit, and protected by comprehensive access controls.
Data residency, EU only
All customer data (databases, files, task queues, audit logs) is stored in EU data centers.
- Database
- AWS, EU region
- Agent Service
- GCP, EU region
- File Storage
- GCP, EU region
- Task Queue
- GCP, EU region
A note on LLM inference
By default, when an agent invokes an LLM, the request goes to the selected model provider (Anthropic, OpenAI, Google, or another) and is processed in their region. EU-hosted models with inference in the EU are available, and admins decide which models agents may use. Customer data at rest, audit logs, files, and configuration stay in the EU.
Encryption
- At rest
- AES-256 for all stored data
- In transit
- TLS 1.2+ / HTTPS for all communication
- Secrets
- RSA-OAEP with SHA-256
- User content
- Sandboxed on a separate usercontent subdomain with its own CSP
Compliance status
- GDPRCompliant· EU data residency by default
- EU AI ActAligned· Transparent decision logging, human-in-the-loop, EU residency
- ISO 27001Certified· European focus, broadly recognised, the right baseline first
- SOC 2 Type IIPlanned· Certification planned
- Data encryptionMet· AES-256 at rest, TLS 1.2+ in transit
- Access controlsComprehensive· Role-based permissions across workspace, team, and agent
We chose ISO 27001 first because it is European-led, broadly recognised across our customer base, and the right foundational standard for the AI sector. SOC 2 Type II certification is planned.
Audit trails
Every agent action is logged with full context. Logs are append-only and protected by the same access controls as the rest of the platform.
- Timestamp: when the action occurred
- Actor: which agent performed it
- Trigger: what initiated it (email, schedule, chat, webhook)
- Plan: what the agent intended to do
- Execution: which tools were called and what happened
- Result: the outcome of the action
Configuration changes (instructions, capabilities, credit limits) are versioned, and the user action log records who changed which agent, team or workspace setting, who invited whom, and when.
Incident response
We follow a defined incident response process with named owners, clear escalation paths, and customer communication built in. As a GDPR-compliant data processor, we notify affected customers without undue delay and within 72 hours of becoming aware of a personal data breach, in line with Article 33.
Monitoring & testing
Production systems are continuously monitored for errors, anomalies, and security events, with alerts routed to engineers for triage. Automated vulnerability scans run on every code change (Dependabot) and every container image we deploy (Google Artifact Registry container scanning). The first independent third-party penetration test is scheduled for H2 2026, with findings tracked through remediation.
Take it organisation-wide
Once the controls exist, governance decides who can use them
Security gives every agent the right guardrails. Governance is how you run hundreds of agents across dozens of teams without losing visibility or slowing anyone down.
See how governance worksOrganise and control
Roles and teams decide who builds and uses each agent. Capability, model and cost limits decide what agents may do and spend.
Deploy safely
Agents move from sandbox to production only after the review steps you define, and changes in production are reviewed again.
Measure and audit
Key metrics show what each agent delivers next to what it costs, and every agent action and configuration change is logged.
Frequently asked questions
Where is our data stored?
Where is our data stored?
All customer data (databases, files, audit logs, task queues) is stored in EU data centers on AWS and GCP. By default, LLM requests go to the selected model provider and are processed in their region. EU-hosted models with inference in the EU are available, and admins decide which models agents may use.
Are you GDPR, ISO 27001, and AI Act compliant?
Are you GDPR, ISO 27001, and AI Act compliant?
Yes. GDPR-compliant with EU data residency by default. ISO 27001 certified. EU AI Act aligned with transparent decision logging, human-in-the-loop controls, and EU residency. SOC 2 Type II certification is planned. Enterprise customers can request a DPA and current compliance documentation.
Can agents be manipulated through prompt injection?
Can agents be manipulated through prompt injection?
Prompt injection is a risk for any agent, so the platform reduces it in layers. Attack detection screens untrusted trigger content in a separate context before the agent acts on it, and guardrails are enforced by platform code (not LLM reasoning), so they do not rely on the model following instructions. Match your configuration to your risk profile.
Does the LLM ever see our credentials or API keys?
Does the LLM ever see our credentials or API keys?
No. The LLM only knows which capabilities are available (e.g., "Gmail: read and send emails"). When an agent calls an external API, the platform injects authentication after the LLM has generated the request, so credentials are never included in prompts or visible to the model.
How do we govern agents across a large organisation?
How do we govern agents across a large organisation?
Mirror your org chart. Use workspaces per business area (or one workspace with teams as departments for smaller orgs). Workspace admins set the ceiling (capabilities, models, MCP, allowance), team admins govern their function (budgets, capability approvals, analytics), and agent owners configure per-agent guardrails inside those limits.
Can we have a dedicated deployment?
Can we have a dedicated deployment?
Yes, for enterprise customers. A dedicated deployment gives you your own database and your own agent service on dedicated infrastructure, separate from the shared multi-tenant platform, while keeping the same EU residency and security posture. Contact our team to scope it for your organisation.
Build agents your security team can sign off on
Get the full security overview in our documentation, or talk to our team about your governance requirements, DPAs, dedicated deployment, and custom compliance arrangements.