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
Security overview
Built for enterprise security
The essentials your security and compliance team will ask about. Each topic is covered in depth further down the page.
Data residency
EU only
Databases, files, audit logs, and task queues are stored exclusively in EU data centers on AWS and GCP.
Encryption
AES-256 at rest, TLS 1.2+ in transit
All data is encrypted in storage and on the wire. Secrets are protected with RSA-OAEP and never reach the LLM.
ISO 27001
Certified
Audited against the international information-security management standard, with a European focus that maps cleanly to most procurement reviews.
EU AI Act
Aligned by design
Transparent decision logging, human-in-the-loop approval, and EU-only residency match the obligations relevant to enterprise AI deployments.
GDPR
Compliant by default
EU residency from day one, Data Processing Agreements available, and full data-subject rights respected end to end.
Audit trail
Every agent action logged
Trigger, plan, execution, and outcome are captured immutably for every action. Agent actions are auditable in the activity log in real time.
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 the agent cannot talk its way past
- 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 manipulation never reaches it.
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 agent cannot bypass them with clever prompting because the check happens before the action executes.
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 the agent cannot override
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. The agent never gets a chance to override them.
| 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-level controls
Some controls belong at the workspace, not the individual agent. Workspace and team admins set the ceiling everyone else operates inside.
Capability toggles
Enable or disable specific capabilities workspace-wide. Capabilities disabled here cannot be enabled per-agent.
Admin restriction tiers
Set sensitive capabilities to None, Admin, or Team admin. Workspace admins decide which capabilities regular members can pick, and which require an admin.
Custom MCP servers
Allow or block users from adding their own MCP servers to extend their agents.
Model selection
Control which LLM models are available to users and agents for new work, on top of the platform-wide list. Useful for cost control or standardising model usage.
Attack-detection alerts
Choose where blocked-attack alerts go (admins, additional emails, or a custom list) and whether to include the blocked payload for debugging.
Daily and monthly usage limits
Cap credit usage per agent (daily), per team (monthly), and at the workspace level. Limits are enforced at the platform level and prevent runaway costs.
Dedicated deployment for enterprise
For organisations that need physical separation from other tenants, Abundly offers a dedicated deployment option. 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 physically separate.
Dedicated deployment is an enterprise-tier offering and priced separately. Contact our team to scope a deployment 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
When an agent invokes an LLM, the request is routed to the selected model provider (Anthropic, OpenAI, Google, or another) and processed in their region. Customer data at rest, audit logs, files, and configuration never leave 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 IIIn progress· Audit cycle underway
- 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 now in progress.
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. The exact level of "who-changed-what" attribution is being tightened. Contact our team for current details if this is critical to your compliance review.
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 set policy across hundreds of agents and dozens of teams, without losing visibility or slowing anyone down. Workspaces, teams, and admin oversight, modelled after how your business is structured.
See how governance works at scaleWorkspace · Team · Agent
Three tiers of control. Workspace admins set the ceiling, team admins govern their function, agent owners build inside those limits.
Cost governance at every level
Workspace allowance, team monthly budgets, and per-agent daily limits. Each level warns or blocks independently.
Admin oversight without overreach
Private agent visibility for compliance, workspace analytics, scoped secrets, and a complete activity log. Govern without micro-managing.
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. When an agent invokes an LLM, the request goes to the selected model provider in their region, but customer data at rest stays in the EU.
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 in progress. Enterprise customers can request a DPA and current compliance documentation.
Can agents be manipulated through prompt injection?
Can agents be manipulated through prompt injection?
Only if badly designed. 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 cannot be bypassed by clever prompts. 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, physically separated from the shared multi-tenant infrastructure, 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.