Skip to main content
CAPTIVOLTTECHNOLOGIES
Discuss Your AI Initiative

Security

Nine security questions, answered plainly.

For each question: what this website does in its own code, how client systems are handled, and what is not yet published or verified, stated as such rather than left out.

The questions, and where each answer stands.

Every trust area, and where each stands →

Data and access

Where data is, and who can reach it.

Where does customer data run?

Partly answered

Client systems are designed to run in the client’s own environment. Data sent through this website is held on Captivolt’s hosting.

On this website

  • Enquiries, diagnostic answers and resource requests are stored in this website’s database, hosted on Amazon Web Services.

In client engagements

  • Client systems are designed to run in the client’s environment (their cloud, a private VPC or a hybrid estate), and Captivolt’s accelerators are installed there rather than hosted by Captivolt.

The hosting region, encryption at rest and backup arrangements for this website are not yet verified, so none of them is stated here.

Privacy Policy →

Who can access it?

Answered

For this website, signed-in administration accounts, and every view is recorded. For client systems, the people the client grants access to, for the work agreed.

On this website

  • Submitted data can be seen only through signed-in accounts in this website’s administration console.
  • Viewing enquiries, diagnostic submissions or resource requests is recorded in an audit trail, as are sign-ins, failed sign-ins, account lockouts and erasures.

In client engagements

  • Captivolt engineers’ access to client systems and data is agreed per engagement and limited to what the work needs, following least privilege.

How is access controlled?

Answered

By role, by hashed credentials that lock after repeated failures, and by keeping the data API off the internet.

On this website

  • Administration is split into viewer, editor and admin roles, and publishing requires admin.
  • Passwords are stored as salted hashes, and repeated failed sign-ins lock the account without revealing whether it exists.
  • The API that stores submitted data listens only on the server’s own loopback interface, so it cannot be reached from the internet. Only this website’s server calls it, with a key that browsers never see, checked in constant time.

In client engagements

  • Access control and data classification are designed into AI systems, so retrieval and agents respect the entitlements of the person asking.
  • Retrieval runs under the caller’s permissions rather than a shared service account, with enterprise identity integration where required.

Operations

Secrets, vulnerabilities, logs and incidents.

How are secrets managed?

Partly answered

Kept out of the code and out of every deployment, and supplied to the services on the server.

On this website

  • No secret is committed: environment files are excluded from the repository, which tracks only examples without values.
  • Database credentials and the session-signing key are supplied to the services as environment configuration held on the server, outside the repository and outside every deployment.
  • Deployment credentials are held as encrypted secrets in the CI system.

In client engagements

  • How secrets are stored and rotated in client systems is agreed per engagement.

No rotation schedule for this website’s secrets is published yet.

How are vulnerabilities handled?

Partly answered

JavaScript dependencies are audited on every change and backend dependencies are pinned. A disclosure policy is not yet published.

On this website

  • JavaScript dependencies are audited on every change, and a high-severity finding stops the deployment.
  • Backend dependencies are pinned to exact versions, so an upgrade is a deliberate change rather than an incidental one.
  • Every response carries a content security policy that forbids other sites from framing this one, HTTP Strict Transport Security, and headers that stop content-type sniffing and limit what the referrer and the browser expose.

In client engagements

  • AI-assisted delivery is governed by release gates for evaluation, security and approval.

Backend dependencies are not yet audited automatically, and there is no published vulnerability disclosure policy. Until there is, report a suspected vulnerability to contact@captivolt.com with “Security” in the subject line.

AI-Native SDLC Blueprint →

What logs are kept?

Partly answered

An append-only audit trail, and structured application logs that can be tied back to it.

On this website

  • The audit trail is append-only: records are never edited or deleted, including when the personal data they refer to is erased. Each records the action and the account, and where a request caused it, the request identifier and source IP address. Message bodies are never written to it.
  • Application logs are structured, one JSON record per line, and carry the request identifier, so a log line can be tied to the audit record it belongs to.

In client engagements

  • Audit logging is designed into agentic and RAG systems so actions are traceable, including which sources were read under whose access.

No retention period is set yet for the audit trail, the application logs or the web server’s logs, so none is stated.

How are incidents managed?

Partly answered

A faulty release can be rolled back by a written procedure. A public notification commitment is not yet published.

On this website

  • A faulty release is rolled back by redeploying an earlier version, following a written procedure.

In client engagements

  • Escalation paths and response playbooks for AI-related events are designed into the systems we build.

No public incident notification commitment is published yet. For client engagements, notification terms are set in each agreement.

AI and deployment

Model providers, and where systems run.

How are AI providers handled?

Set per engagement

This website uses none. In client systems, the provider and its terms are chosen per engagement.

On this website

  • This website sends nothing to an AI provider. No model is called anywhere in the site or its backend.
  • The AI Readiness Diagnostic is rule-based: the same answers always produce the same recommendation, and no model is involved.

In client engagements

  • Systems are designed for model-provider optionality rather than lock-in.
  • Which provider is used, where it processes data and what it may retain are agreed per engagement.
Responsible AI Statement →

What deployment options exist?

Answered

Client cloud, private VPC or a hybrid estate, with each accelerator installed in the client’s environment.

In client engagements

  • Client cloud, private VPC or a hybrid estate, with enterprise identity integration where required.
Where each accelerator runs
AcceleratorWhere it runs
Agentic RAG AcceleratorYour cloud, your identity provider, your network boundary. Retrieval runs under the caller’s permissions rather than a service account.
VeriCore AI Evaluation StudioYour environment and your CI/CD, against your systems and your data. Evaluation cases are yours and do not leave.
AegisIQ AI Governance WorkbenchYour environment, alongside the systems it records. It holds references and evidence rather than copies of the data those systems hold.
AI Automation BlueprintYour environment, connected to your systems of record through approved integrations rather than screen automation.
AI-Native SDLC BlueprintYour repositories, your CI/CD and your review process. Nothing moves to a Captivolt platform.

Working through a security review?

Bring the questionnaire. Where an answer depends on an engagement, it is set in that engagement’s agreement.

Discuss data, security & governance