Security

The controls your security team expects. Documented the way they want to read them.

Encryption in transit and at rest. Role-based access control. Workspace isolation. AI-native primitives - sub-agent isolation, credential vaulting, sandboxed tool execution. Audit trail on every action. We don’t claim certifications we don’t have, and we document everything else.

Talk to us

Last updated: May 13, 2026

Data: Encryption · Isolation · Residency
Audit: Full trail · SIEM export · Retention 90d+
Access: RBAC · SSO · Workspace scope
Compliance: SOC 2-aligned · GDPR · DORA-ready
AI-native: Sub-agent isolation · Credential vault
Infra: Cloud · Hybrid · On-prem · MCP sandbox

Approach

Security is part of the architecture, not a layer on top.

The free tier and the enterprise tier run on the same security model. RBAC, audit, credential vaulting, and workspace isolation are part of the runtime - not features that activate at a higher pricing tier. The difference between free and enterprise is scale, SLA, and deployment options. The security baseline is constant.

01
Least privilege by default
Every agent, every user, every tool call operates under explicit permission scopes. Permissions are additive, not subtractive - nothing has access until access is granted.
02
Auditable by default
Every agent action, tool invocation, knowledge retrieval, configuration change, and human override is logged. Audit is on by default, off only by explicit configuration.
03
Isolated by default
Workspaces, agents, sub-agents, knowledge bases, credentials - all isolated by default. Cross-resource access is explicit, named, and logged.

Data protection

Encrypted. Isolated. Never used for training.

Customer data flows through the platform under encryption, isolated by workspace, and is never used to train external models. Detail below.

3A · Encryption

Encryption

In transit: TLS 1.3 for all client-to-platform and platform-to-LLM connections. Older TLS versions explicitly disabled.
At rest: AES-256 for all stored data - knowledge base content, embeddings, conversation history, audit logs, configuration.
Key management: AWS KMS for cloud deployments. Customer-managed KMS available on Enterprise tier. On-prem deployments use customer KMS.
Field-level encryption: PII fields can be encrypted with customer-controlled keys before being stored. Configurable per workspace.

3B · Workspace isolation

Workspace isolation

Logical isolation at the database layer - workspace ID enforced in every query, no cross-workspace queries possible.
Network isolation for Enterprise tier - dedicated VPC/private subnet per customer optional.
Compute isolation for on-prem - entire runtime in customer environment, no shared infrastructure.

3C · Data residency

Data residency

EU residency available on Cloud tier - data stays in EU regions, processing happens in EU regions.
US residency available on Cloud tier.
Custom residency available on Hybrid and On-prem tiers - customer controls all data locations.
LLM provider data flow documented per provider. Customers can pin specific provider regions for compliance (e.g., Anthropic EU endpoints, OpenAI EU endpoints).

3D · Training data policy

Training data policy

No customer data used to train AgentX models - full stop. Documented and enforceable.
LLM provider terms - customers can use their own commercial agreements with LLM providers (Anthropic, OpenAI, Google) for stronger data protection terms.
Opt-out by default - customer conversations are never sent to LLM providers’ training pipelines under our default configuration.

Access control

Least-privilege at every layer.

Access control operates at four layers: workspace, user, agent, and tool call. Each layer is independent, enforced separately, and audited.

Workspace-level

Workspaces are the primary isolation boundary
Users invited to specific workspaces; access elsewhere requires re-invitation
Workspace-level admin can manage members, agents, integrations
Cross-workspace data flow requires explicit configuration and is logged

User-level

RBAC: Admin, Editor, Viewer roles per workspace
Granular per-resource permissions (per-agent, per-knowledge-base, per-integration)
SSO via SAML 2.0 and OIDC - Azure AD, Okta, Google Workspace, Auth0, OneLogin
MFA enforced via SSO provider policy
Just-in-time user provisioning supported via SCIM

Agent-level

Each agent sees only the knowledge, tools, and credentials explicitly granted to it
Sub-agents inherit permissions from their parent orchestrator - but can be further restricted
Sub-agents cannot be invoked directly by users who lack permission on the parent orchestrator
Agent permissions logged and exportable

Tool call-level

Tool calls execute under the agent’s permission scope, never the user’s
Each tool call logged with parameters, response, latency, cost
Rate limits configurable per workspace, per agent, per tool
Tool failures route to fallback or human review queue - no silent failures

AI-native primitives

The security primitives that exist because AI agents exist.

Generic SaaS security covers credentials, encryption, and access control. AI agent platforms introduce new attack surfaces: prompt injection, sub-agent reverse engineering, tool call abuse, model output exfiltration. We treat these as primary threats, not afterthoughts.

For the broader AI risk and governance framework - model risk management, explainability, drift monitoring - see AI Governance

Sub-agent isolation

The orchestrator coordinates sub-agents. End users interact only with the orchestrator. Sub-agents cannot be addressed directly through the orchestrator’s interface - prompt injection attempts at the orchestrator cannot reverse-engineer or directly invoke sub-agents.

Credential vault separation

OAuth tokens, API keys, and secrets are stored in a workspace-scoped vault - encrypted at rest, never exposed to agent context. When an agent calls a tool, the platform makes the call on the agent’s behalf with vaulted credentials. The agent never sees the credential.

Prompt injection containment

Multi-layer defense: input sanitization at the orchestrator boundary, sub-agent role enforcement at the team level, output validation at the tool call boundary. Prompt injection is treated as an ongoing threat, not a one-time mitigation.

Sandboxed tool execution

Custom Python tools execute in isolated sandboxes - no filesystem access outside designated paths, no network calls outside whitelisted endpoints (configurable per workspace), CPU and memory limits enforced per execution.

Output validation

Agent outputs can be validated against structured schemas before being returned to users or downstream systems. Validation failures route to fallback or human review.

Infrastructure

Runs where you need it to run.

Three deployment models. Same security baseline across all three. The difference is who operates the underlying infrastructure.

01AgentX-managed

Cloud

Hosting: AWS, multi-region
Network: Private subnets, security groups, no public access to internal components
Encryption: TLS 1.3 + AES-256, AWS KMS
DDoS protection: AWS Shield Standard, optional AWS Shield Advanced on Enterprise
Monitoring: 24/7 platform monitoring, on-call rotation
Patching: Managed by AgentX; security patches deployed within SLA windows

02Customer VPC

Hybrid

Runtime: Deployed in customer’s AWS, Azure, or GCP account
Network: Customer’s VPC, customer’s network policies
Data plane: Stays in customer environment
Control plane: AgentX-managed, communicates with runtime via signed/encrypted channels
Compatible with: Customer’s existing IAM, KMS, VPC peering, private link, transit gateway
Patching: Co-managed; AgentX provides updates, customer applies on their schedule

03Fully isolated

On-premise

Runtime: Inside customer perimeter - VPC, data center, or air-gapped
Network: No external dependencies required for core operation
LLM: Self-hosted (Llama, Mistral, custom) or customer-routed (private LLM endpoint)
Updates: Delivered as signed packages; customer applies via their change management process
Air-gapped: Supported for regulated environments
Patching: Customer-operated; AgentX provides update artifacts and runbooks

For deployment process detail - environments, residency, integration patterns - see Deployment

Secure MCP execution

Third-party tools, executed under controlled conditions.

MCP servers and custom tools extend an agent’s capabilities - and its attack surface. We sandbox every tool execution, scope every credential, and log every call.

Sandbox execution

Every tool call runs in an isolated execution environment with explicit resource limits and network policies.

Egress allowlisting

Outbound network calls from tools restricted to allowlisted endpoints. Per-workspace and per-tool configurable.

MCP server vetting

Official MCP marketplace tools are reviewed for security posture before being made available. Customer-installed MCP servers retain customer’s risk; we provide isolation, customer provides selection criteria.

On-prem MCP

MCP servers can run inside the customer perimeter. AgentX agents call them via signed connections that never expose customer data to AgentX infrastructure.

Audit

Every action, logged. Every log, exportable.

Audit logs are a first-class part of the platform - not a feature behind a paywall. Every agent action, tool call, configuration change, permission change, deployment, and human override is logged with full context. Logs are retained, searchable, and exportable to your SIEM.

What gets logged

Agent invocations (input, output, model, tokens, cost, latency)
Tool calls (tool name, parameters, response, latency)
Knowledge retrievals (KB ID, query, retrieved chunks)
Sub-agent handoffs and delegations
Human-in-the-loop interventions
Configuration changes (who, what, when, prior value)
Permission grants and revocations
Deployments and rollbacks
Failed authentication attempts
API access patterns

Where logs go

Built-in dashboard - searchable in the AgentX UI for 90 days standard, configurable up to 365 days on Enterprise
OTel export - distributed traces via OpenTelemetry to Datadog, Honeycomb, New Relic, Grafana, any OTel backend
SIEM export - structured audit logs to Splunk, Sentinel, Chronicle, or via syslog/CEF format
S3 / object storage - raw log export for long-term archival
Webhook stream - real-time event stream for custom integrations

Vuln mgmt & IR

How we find issues. How we respond when issues find us.

Security operations cover both proactive (find before they’re found) and reactive (when something breaks). Both processes are documented.

Proactive

Static analysis in CI pipeline for all platform code
Dependency scanning with automated alerts on CVE disclosures
Penetration testing by third party - annual minimum, after major releases
Bug bounty program - coming Q3 2026; until then, security reports via security@agentx.so
Code review required for all changes to security-sensitive components

Reactive

Incident response plan documented, tested via tabletop exercises
24/7 on-call for cloud platform incidents
Customer notification SLA - within 72 hours of confirmed incident affecting customer data; faster for confirmed breach
Post-incident review with customer (if affected) and internal team
Status page - status.agentx.so for platform health and incident updates

Compliance

What we claim. What we don’t.

We’re explicit about our compliance posture. Certifications we have, we name. Certifications we’re working toward, we name with timelines. Frameworks we align to without certification, we name as alignment - not compliance.

10A · Certifications

Certifications

In progress
SOC 2 Type II - audit in progress, expected completion Q3 2026. Until certified, controls documented in security overview document.
Roadmap
ISO 27001 - roadmap, target 2027.

10B · Frameworks we align with

Frameworks we align with

We build the platform with the following frameworks in mind. We do not certify against them - your team certifies with us in the stack.

GDPR - data protection, residency, subject rights workflows supported
DORA (EU Digital Operational Resilience Act) - third-party risk, incident reporting, operational resilience controls
EU AI Act - risk classification, transparency, human oversight, documentation
SR 11-7 (US Federal Reserve model risk guidance) - model validation, monitoring, governance
MAS (Monetary Authority of Singapore) - technology risk management guidance
HKMA (Hong Kong Monetary Authority) - supervisory policy on AI
SOX - internal controls supportable via audit trail and HITL configuration

10C · What we provide your compliance team

What we provide your compliance team

Documentation your team can review on their terms. Available on request.

Data flow diagrams per deployment model
Security questionnaire responses (CAIQ, SIG, custom)
Audit log samples and retention policy
Penetration testing summary (annual)
Incident response plan (redacted)
DPA (Data Processing Agreement) - GDPR-aligned template
Sub-processor list

For the broader AI governance framework - model risk management, explainability requirements, regulatory framework deep dives - see AI Governance

The other enterprise deep dives.

Security is one of four enterprise pillars. The others cover delivery model, AI-specific governance, and infrastructure deployment.

Enterprise overview

How We Work

Four-stage delivery with decision gates. The process model security operates under.

See process

AI Governance

Model risk management, explainability, HITL design, regulatory framework alignment.

See governance

Deployment

Cloud, hybrid, on-prem deep dive. Data residency, integration patterns, environment options.

See deployment

Ready for the security conversation?

A 30-minute call. No deck. Just answers.

Bring your security questionnaire. Bring your compliance officer. We’ll walk through deployment model, data residency, access control, and audit - and tell you what we have, what’s roadmap, and what won’t fit your requirements. Honest is faster.