Skip to content
Vertix

Security and trust

What stops the agent, and what we have not built yet.

VertixOS is an operating system for AI agents doing real business work: every action is risk-tiered before it runs, anything irreversible waits for a named person, and every decision is written down. This page is the version of that story a security reviewer needs — the controls that are in place, the ones that are not, and the certifications we do not hold.

Request the security packSee the mechanism

Sent to a named person at the company evaluating us, under an NDA if you want one.

Last reviewed · reviewed at every release

Certifications

We hold none. Here is the whole list.

This is the first thing on the page on purpose. You would find it out anyway, and the order in which you find it out decides whether you believe the rest.

  • What buyers ask for
    SOC 2, Type I or Type II
    Status
    Not held
    What is true today
    An independent attestation is in progress. We will publish the report date when there is a report, and not one day before it.
  • What buyers ask for
    ISO 27001 and ISO 42001
    Status
    Not held
    What is true today
    Neither is held and no control mapping is published. Mapping our controls to ISO 42001 and to the NIST AI risk framework is scheduled; when it exists the page will say “mapped to”, which is a weaker word than the one vendors usually reach for, and the correct one.
  • What buyers ask for
    HIPAA and a signed BAA
    Status
    Not held
    What is true today
    No business associate agreement is executed today. The product is built for regulated work, and a HIPAA-eligible deployment profile with a BAA is on the roadmap. Until one is signed, protected health information does not belong in a workspace, and we will say so on the call rather than let you assume otherwise.
  • What buyers ask for
    Independent penetration test
    Status
    None on record
    What is true today
    There is no third-party test to show you. One is scheduled as part of the attestation programme, deliberately after the isolation and encryption work rather than before it. When it runs we will publish the summary, including what it found.
  • What buyers ask for
    Published uptime, SLA, status page
    Status
    Not published
    What is true today
    We publish no availability figure and offer no SLA, because we do not yet measure availability in a way we would defend in a contract. Continuity commitments belong in an agreement, not on a marketing page.

An attestation is worth having and we are working toward one. What it tells you is how a company manages its laptops, its access reviews and its vendors. What it does not tell you is what stops an agent from issuing a refund at two in the morning, which is the question you opened this page with. Ask every vendor on your shortlist the second question, and notice how many answer it with a badge.

Until each row above changes, we will not imply otherwise — in copy, in a deck, or on a call. You can check that we have not, which is rather the point of writing it down.

Controls in place

Grouped the way you read, not the way we built it.

Each control says what it does and whether it is complete. Where something is partial, it says partial.

  • Identity and access

    Who — or what — is acting, and how that is established on every action rather than once at login.

    Scoped, recorded agent identityLive
    Agent credentials are scoped to the work, stored hashed rather than in the clear, and recorded in use. Identity and permission are resolved per action, not cached from a session.
    The ceiling lives in the runtime, not in the credentialLive
    An unattended agent is capped below anything irreversible by the runtime that executes the work. A credential that leaks does not carry the ceiling with it, which is the difference between a stolen token being an incident and being a catastrophe.
    Human access to productionLive
    Limited to a small set of named people and recorded. Scheduled access reviews with retained evidence are part of the attestation work rather than something we can show you today.
    Customer-managed agent identities and rotationPartial
    Per-agent identities that you create, scope and rotate yourself are in progress. Today we issue and rotate them for you as part of the engagement.

  • Tenant isolation

    The oldest multi-tenancy question, now with an autonomous actor asking it.

    Enforced by the database, not only by application codePartial
    Your workspace boundary is enforced in the database under a role that cannot bypass it, so a bug in application code does not become a cross-tenant read. We are extending that enforcement across the full surface and having it independently tested. The control inventory, at route level, is in the security pack.
    Relationship-based authorisation, failing closedLive
    A dedicated authorisation service answers who may act on what. When it cannot answer, the action is refused rather than allowed — the direction of the default is the whole point.

  • Agent-specific controls

    The section most vendor security pages do not have. The mechanism, in full, is on the governed autonomy page.

    Every action carries a risk tierLive
    Actions are classified before they run, and the tier — not the model’s confidence — decides what happens next. The tier table is published in full rather than described.
    A hard ceiling on unattended workLive
    Anything that publishes, pays, deploys or deletes is above what an unattended agent may execute. It is not a prompt instruction and not a configuration flag an agent can reach.
    Human-only approvalLive
    Approval routes accept a human actor. An agent cannot approve its own work, and a model-generated confirmation — typed or spoken — is not a signature.
    Tools filtered by policy before the model sees themLive
    A tool outside the allowed set is not offered and cannot be called, however persuasive the prompt that asks for it.
    Memory advises and never authorisesLive
    Recalled context is labelled advisory and scoped to your workspace. A remembered fact can inform a decision and can never grant a permission, so a planted memory has nothing to unlock.

  • Secrets

    The failure mode here is quiet: a credential ends up in a prompt, a log line, or a support transcript.

    Referenced, never inlinedLive
    Credentials live in a secret store and are injected at runtime by reference. Raw-secret markers are rejected at the boundary, and no secret is carried into a prompt or written to a log.
    Treated as compromised once exposedLive
    A credential that appears anywhere it should not — a chat, a log, a commit — is rotated rather than reused. That rule is in our own engineering contract, which is where rules of this kind actually have to live.

  • Audit and traceability

    What you would ask for if something went wrong, and what you can get today.

    Every outcome writes an eventLive
    Completed, failed, denied, waiting for a person — each is an event, tied together by one correlation id. A refusal is as visible as an execution, which is the part most audit trails quietly omit.
    Walkthrough today, export not yetPartial
    We query the trail with you and walk an auditor through it. A self-service bundle you download for a single run is not built, and we will not describe a walkthrough as an export.

  • Data handling and model providers

    Where your data goes when an agent thinks, and who else holds it.

    Your data is not training dataLive
    We do not train or fine-tune any model on your data, and nothing you give us becomes training material for a general model.
    Provider list and retention termsPartial
    Subprocessors and model providers are listed, provider by provider with their retention terms, in the security pack. We send the current list rather than publish a snapshot that goes stale — and a provider you rule out is a decision made with you during delivery, not one you inherit.
    ResidencyPartial
    Production runs in one region today on infrastructure we operate. Choosing a region, or running inside your own environment, is a delivery engagement rather than a setting. If residency is a hard requirement, raise it in the first ten minutes.
The agent-specific controls above are the short form. The mechanism — the full tier table, the threat-to-control map, and a demonstration you can try without signing up — is on the governed autonomy page.

Not yet

Four things a reviewer will ask for that we cannot hand over.

Named, with what each one will be. If one of these is a gate for your organisation, you have just saved yourself a call — and we would rather you saved it here than after a procurement cycle.

  • Downloadable evidence export

    Planned

    What it will be: a bundle you download for any single run — who asked, which agent identity and policy version ran, the tools offered against the tools actually used, approvals with their approvers, the checks and their results, and the costs. The events behind it exist today and we walk through them with you. The artefact an auditor wants to keep does not exist yet, and a walkthrough is not the same thing.

  • Enterprise single sign-on with directory provisioning

    Planned

    What it will be: SSO per tenant, plus directory provisioning so that removing someone from your identity provider removes them here, the same day, without anyone remembering to. Designed, not built. Until it ships, account lifecycle is handled as part of the engagement, with the specifics set out in the security pack.

  • Workspace spending ceilings

    Partial

    What runs today: per-run step and cost limits, loop detection, and provider circuit breakers, with each trip written to the ledger. The workspace-level spending ceiling is in preview and being productised. Until it lands we set limits with you at the run and agent level, rather than claim a ceiling the platform does not yet enforce on your behalf.

  • Verification of general business work

    Partial

    What runs today: on governed software delivery, work is checked by a different model family before a goal can close, with evidence attached and two approvals recorded. Extending that to copy, customer replies, documents and record changes is being productised and is the largest single item on our roadmap. Until it ships, verification of business work means a person approving it, not a second model.

A note on what this page deliberately does not say

For every control above we tell you what it does and whether it is complete. We do not publish which routes, modules or hosts a partial control has not reached yet. That is not modesty. A public list of the places a control has not landed is a target list, and publishing one would make the customers we already have less safe while making our marketing look braver.

The full inventory at that level of detail is in the security pack, which goes to a named person at a company evaluating us, under an NDA if you want one. If you think we have used that sentence to duck something on this page, say so in the request and we will either answer it or tell you plainly why we will not.

Pre-answered

The questions you were going to send us anyway.

The fifteen a regulated buyer actually asks about AI agents, answered straight, including the ones where the answer is not yet. Quote the number if you want one expanded.

Q-01Who are your subprocessors, and which model providers can see our data?
The current list, with what each one processes and the retention terms we hold with them, is in the security pack. We send the live list rather than publish a snapshot, because it changes and a stale page is worse than no page. If a specific provider is unacceptable to you — several regulated buyers have one — say so at the first call: which model families are allowed for your work is a decision we make with you, not one you inherit.
Q-02Do you train models on our data?
No. We do not train or fine-tune any model on your data, and nothing you give us becomes training material for a general model. Provider terms differ on whether API traffic may be retained, which is why the pack lists them provider by provider instead of making one blanket promise on their behalf.
Q-03Where is our data stored, and can we choose the region?
Production runs in one region today, on infrastructure we operate. Choosing a region, or running the platform inside your own environment, is a delivery engagement rather than a switch in a settings page. If residency is a hard requirement, tell us in the first ten minutes; it changes the shape of the work, and occasionally the honest answer is no.
Q-04How long do you keep our data, and what happens when we leave?
Retention is set in the agreement rather than by a default we chose for you, and you can ask for an export or a deletion at any point. What does not exist yet is a self-service retention control per data class inside the product: today, changing retention is a request to us, which we action and confirm in writing.
Q-05Is our data encrypted?
Traffic to the platform is served over TLS. We are not going to tick the rest of this box on a public page: the state of each encryption control, including the ones we are still completing, is in the security pack rather than here, because the operational detail of an incomplete control is exactly what an attacker would like to read. What we will not do is describe it as finished. If encryption at rest under your own key is a gate for you, ask before the call and we will answer in writing.
Q-06Who at your company can see our data?
A small, named set of people, and the access is recorded. Credentials are held in a secret store and referenced rather than copied around, and no secret is carried into a prompt or written to a log. Scheduled access reviews with retained evidence are part of the attestation work rather than something we can demonstrate today.
Q-07What happens in an incident, and when would we hear?
We commit to telling you without undue delay, and within 72 hours of confirming an incident that affects your data: what we know, what we do not yet know, and what we are doing about it. There is a written response procedure and a named person responsible for it. What is not in place is an externally exercised response programme or a public status page; both sit with the attestation work.
Q-08Have you had an independent penetration test?
No, and there is no report to show you. One is scheduled within the attestation programme, deliberately after the isolation and encryption work rather than before it, because testing a control you already know is unfinished mostly buys you an expensive document. When it runs, we will publish the summary, including the findings.
Q-09What is your uptime commitment and your continuity plan?
We publish no availability figure and offer no SLA today, because we do not yet measure it in a way we would defend in a contract — and an invented number is precisely the kind of claim that ends up in front of a regulator. Backups run and the restore procedure is written. Published recovery objectives and a public status page are scheduled; the continuity commitments we are prepared to make today go into the agreement rather than onto this page, where they would be worth nothing.
Q-10What stops one tenant from reaching another tenant’s data?
The boundary is enforced by the database under a role that cannot bypass it, rather than only by application code that a bug can route around. We are extending that enforcement across the full surface and having it independently tested, and the route-level inventory is in the pack. It is the control we would look at hardest in your position, which is why we would rather walk through it with you than compress it into a sentence here.
Q-11What do you log, and can we have it?
Every action writes an event for each way it can end — completed, failed, denied, or waiting for a person — tied together by one correlation id. Today we query that with you and walk you through it. A downloadable evidence bundle for a single run is on the roadmap rather than in the product, and a SIEM feed comes after it.
Q-12How do you handle prompt injection?
Two ways, and only the second one really counts. Retrieved content is fenced as data rather than as instructions, which raises the bar. More importantly, the model never holds the authority an injection is trying to reach: tools are filtered by policy before the model sees them, anything irreversible sits above the ceiling an unattended agent can execute, and memory advises without ever granting a permission. An injection that convinces the model still has nothing to spend.
Q-13How is an agent identified, and what can it do on its own?
Each agent identity is scoped, stored hashed, and recorded in use. The ceiling for unattended work is enforced in the runtime rather than carried in the credential, so a leaked credential does not carry the ceiling with it. Customer-managed identities with self-service rotation are in progress; today we issue and rotate them for you.
Q-14Where does a person have to be involved?
At every action classified as external, irreversible or regulated: sending to a customer, publishing, spending, paying, deleting, deploying, filing. Approval routes accept a human actor only, so an agent cannot approve its own work, and a model-generated confirmation — typed or spoken — is not a signature. The tier table that defines all of this is published in full on the governed autonomy page.
Q-15Do your own people or agents act inside our workspace?
Under managed operations, yes, and you are right to ask. They act under the same tiers as your own agents and leave the same trail, so what we did inside your workspace is a query rather than a conversation. If you would rather no third party had standing access at all, that is a fair requirement: it changes the shape of the engagement rather than ending it, so raise it early.
Send us your own questionnaire and we will complete it, including the rows where the answer is no. We have yet to meet a buyer who was annoyed by a blank being called a blank.

Reach us

If you have found something, tell us.

Write to victor@vertixone.com with SECURITY in the subject line. It reaches a person rather than a queue. A dedicated disclosure address and a formal policy page are part of the trust centre work; until they exist, this is the route that actually works, and we would rather give you that than something tidier that bounces.

What we commit to

  • We acknowledge within two business days.
  • We tell you what we intend to do and roughly when, then either fix it or explain why we have not.
  • We credit you by name if you want the credit, and stay quiet if you do not.
  • We will not pursue legal action over good-faith research that stays inside the boundaries opposite.

What we ask

  • Test against your own workspace and your own data.
  • If you reach data that is not yours, stop at the proof. Do not collect it, and tell us immediately.
  • No denial-of-service, no load testing, and no social engineering of our people or anyone else’s.
  • Give us a reasonable window before you publish.

What we do not offer

  • There is no paid bounty programme today, and we would rather say so now than after you have spent a weekend on it.
  • There is no public hall of fame yet. If that matters to you, ask, and we will agree something in writing before you start.

The pack

Ask for the detail this page will not print.

The security pack carries the control inventory with a maturity rating on every line, the subprocessor and model-provider list with retention terms, the threat-to-control map, and the dates we are prepared to be held to on the attestation work. Tell us who is reviewing and what you need answered.

Request the security pack

A person replies within one business hour. If we are the wrong fit for your risk appetite, we will say that instead.

Last reviewed . This page is reviewed at every release, and the review changes the page whenever the truth changes.