Data access & integration security

Security teams handle sensitive data. That is the job. The last thing you need is a risk intelligence platform that becomes a new risk itself.

Draxis was built with that tension in mind. You have four ways to connect your environment, each with its own access model, risk profile, and level of control. None of them ask you to trust Draxis blindly.

Four ways to connect

Choose the integration model that matches your organization’s data-sensitivity requirements. Many customers use more than one.

Native integrations

Draxis holds read-only credentials into your tool stack.

How it works: Draxis is granted a read-only service account or API token for each integrated tool (EDR, SIEM, IdP, vulnerability scanner, and similar). It uses those credentials to pull KRI signals on a schedule. Nothing is written back. Draxis can read, not act.
What Draxis can see: signal data from your integrated tools, such as scan results, login events, policy states, and alert volumes. Not raw logs. Not user content. The structured outputs those tools are designed to expose.
What Draxis cannot do: make changes to your environment. No modifying policies, deleting records, triggering alerts, or executing commands. Access is strictly read-only and scoped to the data required to extract KRI signals.
Risk to understand: if Draxis were ever compromised, an attacker would gain the same read-only visibility into your tool stack that Draxis holds. They could not make changes, but they could see what Draxis sees.
Best for: organizations that want the broadest signal coverage with the least manual effort, and are comfortable with a read-only credential model secured by the platform controls described below.

MCP integrations

The same read-only access model as native integrations, delivered over the Model Context Protocol (MCP) rather than a proprietary API connector.

How it works: where a security vendor exposes an MCP server, Draxis connects as an MCP client using read-only scopes. The access model is identical to native integrations (read-only, scoped, no write-back), delivered through an open protocol instead of a custom integration.
What Draxis can see: the same structured signal data as native integrations, within the scope boundaries the vendor’s MCP server enforces.
Vendor dependency: read-only scope enforcement is the vendor’s responsibility. Draxis requests read-only access; whether the vendor’s MCP server honors that boundary depends on their implementation. Check your vendor’s MCP documentation for scope support.
Risk to understand: the same credential-compromise risk as native integrations. MCP protocol security is also still evolving. The Draxis MCP server is hardened against prompt injection, and every MCP tool call is tenant-scoped, RBAC-bounded, and audited.
Best for: organizations already using MCP-enabled security tools that want a protocol-native integration path as more vendors adopt MCP.

AI Drop Zone

Draxis has no access to your tool stack. You control everything that enters.

How it works: you upload files, paste content, or POST webhook payloads directly to the AI Drop Zone. Draxis reads what you send, extracts KRI signals, and stores those signals in your tenant. The source file is processed and can be retained or discarded per your tenant configuration.
What Draxis can see: only what you explicitly send. Nothing is pulled from your environment, no credentials are held, and no tool connections are made. Extracted KRI signals populate your risk register, trend analysis, and reporting.
Risk to understand: because you control what enters Drop Zone, you also control what sensitive data enters. A pen test report, for example, may contain vulnerability details, exploit paths, or sensitive system information, and Draxis processes (and may retain) that content. For sensitive reports, consider sanitizing or summarizing before uploading, or use external push to send only the extracted KRI values.
Best for: organizations that want zero tool access granted to Draxis, are comfortable managing what they upload, and have the workflow to export data for manual submission.

External push (MCP or REST API)

Maximum control. Draxis receives only what you explicitly send, and nothing else.

How it works: you call your own tool stack from your own approved tooling, extract the KRI value you want to report (the count, the score, the status), and push only that value to Draxis via an MCP tool call or the REST API. Draxis never touches your tools and never sees your raw data.
Example: a penetration test produces a detailed report with vulnerability details, exploit paths, and remediation guidance. With external push, you send one value: “17 critical findings.” Draxis receives the number. The report stays with you.
What Draxis can see: only the KRI values you push. No source data, no tool access, no credentials held. Nothing enters Draxis that you did not send in that exact form.
Risk to understand: signal coverage is limited to what you push, so KRI trends and risk scoring are only as complete as the data you choose to send. This model takes more active management than the others, but it gives the strongest data boundary.
Best for: organizations with strict data-sovereignty requirements, those handling classified or highly sensitive environments, or any customer that requires Draxis to hold no tool credentials and receive no raw data under any circumstances.

Comparison at a glance

	Native	MCP	Drop Zone	External push
Draxis holds tool credentials	Yes	Yes	No	No
Draxis pulls data automatically	Yes	Yes	No	No
You control what enters	No^*	No^*	Yes	Yes
Raw data seen by Draxis	Structured signal only	Structured signal only	Yes (what you upload)	No
Risk if Draxis compromised	Read-only visibility into tools	Read-only visibility into tools	Uploaded content only	KRI values only
Setup effort	Low	Low–Medium	Medium	Medium–High
Signal coverage	Broadest	Broad	Upload-dependent	Push-dependent
Write access to your tools	Never	Never	N/A	N/A

* With native and MCP integrations Draxis pulls automatically, but you still control the scope, roles, and auth each integration is granted into your tool stack. Provision least-privilege, read-only credentials to narrow exactly what Draxis is allowed to read.

Platform security

Whichever integration model you choose, all data that enters Draxis is protected by the following controls. For the full engineering detail, see the Security & compliance doc.

Encryption

Data in transit is encrypted with TLS 1.2 or higher on every external connection, enforced at the global HTTPS load balancer.
Data at rest is encrypted with AES-256 using CMEK keys in Cloud KMS, rotated automatically every 90 days.
Vendor credentials (API keys and OAuth tokens) are stored with application-level column encryption and are never written to logs.

Tenant separation

Every customer operates in a fully isolated tenant.
Row-level security (RLS) is enforced on every tenant-scoped table at the database layer. Postgres itself, not application code, refuses to return rows whose tenant_id does not match the session’s claim, so no query can return another tenant’s data.
Tenant isolation is enforced at the application, API, and database layers.
Partner firms (vCISO/MSP) accessing multiple client tenants are subject to the same RLS controls. A partner can only access tenants explicitly assigned to their account, and any cross-tenant rollup is gated by role claims and audit-logged.

Access controls

Multi-factor authentication (TOTP MFA) is required, with enforcement available per platform, organization, tenant, and user.
Role-based access control (RBAC) governs every platform permission, at both the API and UI layers.
Every MCP tool call is tenant-scoped, RBAC-bounded, and written to the audit log.
SSO (SAML 2.0 / OIDC) is available on the Custom tier.

Audit logging

User actions, API calls, and AI panel interactions are logged. Every write to the platform schema records the actor, action, target, and a structured diff (plus the impersonator identity, where applicable).
Cloud Audit Logs are exported to a separate write-once bucket with 400-day retention, tamper-evident even from the operators running the production account.
Audit data is available to tenant administrators, and tenant export is available on request.

AI and data processing

KRI extraction and AI panel operations run within the platform on Anthropic’s Claude API.
Customer data is never used to train AI models. Claude API queries are processed per session and are not retained for training.
AI model calls are scoped to the requesting tenant. No cross-tenant data is passed into AI processing pipelines.
The MCP server is hardened against prompt injection, and all MCP tool-calling is tenant-scoped and audited.

Infrastructure

Hosted on Google Cloud Platform (GCP) with data residency in the United States.
Cloud Armor sits in front of the load balancer with the OWASP Core Rule Set and per-IP rate limits. Compute has no public IP, and administrative access is tunneled through Identity-Aware Proxy.
A SOC 2 Type II effort is in progress, with controls mapped to the Trust Service Criteria.
Vulnerabilities can be reported under our Vulnerability Disclosure Policy (RFC 9116).

Data retention

KRI signal data is retained per your tenant’s retention policy.
Source files uploaded to the AI Drop Zone are retained or discarded per your tenant configuration.
You can export your data at any time from the platform Settings interface, and may request deletion at any time. When a tenant is deleted, its entire database is permanently removed. See the Data Processing Addendum for controller-processor terms.

Frequently asked questions

Does Draxis use my data to train AI models?

No. Customer data is never used to train AI models. Draxis runs on Anthropic’s Claude API, which processes queries per session and does not retain them for training. No tenant data is passed into model-training pipelines.

Can Draxis make changes to my security tools?

No. All native and MCP integrations are read-only. Draxis has no write access to any tool in your environment under any integration model.

What happens if Draxis is compromised?

The blast radius depends on your integration model. With native or MCP integrations, an attacker would gain read-only visibility into the signal data Draxis can access, the same structured outputs your tools expose to any read-only integration. They could not modify your environment. With Drop Zone or external push, an attacker would only see the data you explicitly sent: KRI values and any uploaded content. Each model’s risk profile is detailed above.

Is my data shared with other Draxis customers?

No. Tenant separation is enforced at the database layer via row-level security, so your data is never accessible to another tenant. Partner firms (vCISO/MSP) managing multiple clients operate under the same controls and can only access tenants explicitly assigned to their account.

Can I use more than one integration model?

Yes. Many customers combine models: native integrations for the primary tool stack, Drop Zone for reports and one-off data sources, and external push for environments with stricter data-sovereignty requirements.

Where is my data stored?

Draxis is hosted on Google Cloud Platform with data residency in the United States. If you have specific region or data-residency requirements, talk to us before onboarding.

Do you have a SOC 2 report?

A SOC 2 Type II effort is in progress, with controls mapped to the Trust Service Criteria. Contact security@draxis.ai for the current status and any documentation available for your security review.

Talk to us

Still have questions about how Draxis handles your data? We are happy to walk through your specific environment, discuss which integration model fits your requirements, and provide documentation for your security review. Email hello@draxis.ai, or reach the security team directly at security@draxis.ai.