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.

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.

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.

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

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.

Cloud

AGENTX-MANAGED

• 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

Hybrid

CUSTOMER VPC

• 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

On-premise

FULLY ISOLATED

• 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 [email protected]

• 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

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 [email protected]

• 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

SOC 2 Type II - audit in progress, expected completion Q3 2026. Until certified, controls documented in security overview document.

IN PROGRESS

ISO 27001 - roadmap, target 2027.

ROADMAP

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.

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.

Talk to us

Start Your AI Automation Journey Today

Get Started - Free

View Pricing

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