SECURITY & GOVERNANCE
Designed into the work.
Not bolted on.
Your security team should be able to see where data lives, who may act on it and what record remains. This page shows each of those as the products are built, and says plainly what is available, what is in development and what we agree with you.
Request security documentationHow to read this page
- Available
Built into the products today, as their own descriptions state.
- In development
Being built. Labelled wherever it appears, and never sold as finished.
- Agreed with you
Settled in discovery and written into your contract, such as hosting, terms, notification and retention.
THE DATA BOUNDARY
Where your data can go.
And where it cannot.
Choose how a product is deployed and a kind of data. The plan draws the rooms it may enter, the doors it may pass and the doors that stay shut, from a person’s own device to an appliance with no outbound link at all.
The appliance Lumen Intelligence, on a Linux VM or Kubernetes that you run.
Your infrastructure Your network and directories. In private mode, the control plane is yours too.
Beyond your boundary Third parties, model providers and the wider internet.
Your directories Passes. People, groups and accounts are read into the appliance, with the evidence behind them.
The privacy gateway Passes, within limits. Sensitive values are removed or pseudonymised before a model sees them. It fails closed.
An external model Passes, within limits. Reached only through the privacy gateway, with pseudonyms in place of sensitive values.
The health link Shut. Counts, health and diagnostics, over a mutually authenticated outbound link you can switch off. In private mode they go to a control plane you host.
Personal dataCustomer-hosted
An appliance on a Linux VM or Kubernetes, inside your infrastructure.
- Where it can go
- Stays in the appliance. A model beyond it sees pseudonyms in place of names and other sensitive values.
- Where it cannot go
- Past the privacy gateway in the clear, or along the health link. If the gateway cannot do its work, it fails closed and nothing is sent.
- Passes
- Passes, within limits
- Shut
- Only if agreed with you
Read every combination as a table
| Data | On a person's device | In a private space | Customer-hosted | Air-gapped | On infrastructure you choose |
|---|---|---|---|---|---|
| Documents and records | Can go. On the person's own device, drawing on your systems only within that person's permissions. Cannot go. Past that person's permissions. Lumen's access is shaped by them. Agreed with you. Whether any document reaches a model, and which model it is. Available | Can go. Worked on inside the space, and passed to your Mac only through the shared folder. Cannot go. Into the rest of your Mac. It is not mounted, and symbolic links are rejected. Available | Can go. The directory records and the evidence behind them are read into the appliance and stay there. Cannot go. Out of the appliance in the clear. Anything sent to a model passes the privacy gateway first. Available | Can go. The directory records and their evidence stay in the appliance, on a network with no outbound link. Cannot go. Out of your infrastructure. Nothing leaves in this mode. Available | Can go. Within the deployment and the systems you connect, as far as each workflow's permissions allow. Cannot go. Past a workflow's permissions. Mesh sets the boundary for each workflow. Agreed with you. Where the deployment runs and where its data is stored. Available |
| Personal data | Can go. With the person's work on their device, gathered only from what they may already see. Cannot go. Anywhere the person could not already see it. Agreed with you. Whether personal data may reach a model at all, and in what form. Available | Can go. Only what a person brings into the space, or places in the shared folder, is there to work on. Cannot go. Your other files on the Mac. The space cannot see them. Available | Can go. Stays in the appliance. A model beyond it sees pseudonyms in place of names and other sensitive values. Cannot go. Past the privacy gateway in the clear, or along the health link. If the gateway cannot do its work, it fails closed and nothing is sent. Available | Can go. Stays in the appliance. Cannot go. Anywhere beyond your infrastructure. Nothing leaves, not even counts or diagnostics. Available | Can go. Only into a workflow that needs it and is permitted to use it, with sensitive actions held for review. Cannot go. Into a workflow that has not been granted it. Agreed with you. Which personal data each workflow may use, and each party's role under data protection law. Available |
| Model prompts | Can go. To the model agreed for your deployment, whether it runs on the device, on infrastructure you control or with a provider you approve. Cannot go. To a model or provider you have not agreed. Agreed with you. Which model, where it runs and the provider's terms for your data. Agreed with you | Can go. To the model agreed for the agent that works in the space. Cannot go. To a model or provider you have not agreed. Agreed with you. Which model the agent uses and where it runs. Running a space in the cloud is planned, not available yet. Agreed with you | Can go. Through the privacy gateway to the model you choose, with sensitive values removed or pseudonymised first. Cannot go. Around the gateway. It fails closed, so a prompt it cannot clean is not sent. Available | Can go. Through the privacy gateway to a model you host inside your boundary, with sensitive values removed or pseudonymised first. Cannot go. To any model beyond your boundary. There is no outbound link. Available | Can go. Under policy, to the provider and model suited to the task, or to a model you run on infrastructure you control. Cannot go. To a provider you have not connected. Bridge routes only among the providers and models you choose. Agreed with you. Which providers you use, and their terms for your data. Available |
| Audit records | Can go. Kept with the work: the sources, approvals and actions behind each result, for the next person to follow. Cannot go. Beyond the device without your agreement. Agreed with you. Where records are kept beyond the device, who may read them and for how long. Agreed with you | Can go. The work happens in view: you watch the space, can take over at any time, and agent input pauses while you do. Cannot go. Beyond the space without your agreement. Agreed with you. Whether a lasting record of each session is kept, and where. Agreed with you | Can go. Every change is written to a hash-chained audit log in the appliance, so an altered entry breaks the chain. Cannot go. Along the health link, which carries counts, health and diagnostics rather than the log. Agreed with you. How long the log is kept, and whether it is also sent to your own security tooling. Available | Can go. Kept in the hash-chained audit log inside the appliance. Cannot go. Anywhere outside your infrastructure. Available | Can go. With the deployment: each decision connected to its inputs, policies and approvals, for your security and risk teams. Cannot go. Beyond your environment without your agreement. Agreed with you. Where records are kept, for how long, and whether they flow to your own security tooling. Available |
An illustrative plan of what each product is designed to allow. Agreed with you marks what is settled in discovery and written into your contract; your own data map is drawn with you before anything is connected.
A REQUEST’S JOURNEY
Every request passes the same checks.
Every answer is kept.
Follow one request from an agent through identity, permission, the privacy gateway and a person’s approval to the record it leaves behind. Then try one that is refused, one the gateway stops and one a person declines.
What remains afterwards?
Evidence record
The decision is connected to its inputs, policy and approval. Lumen Intelligence keeps a hash-chained audit log, so an altered entry breaks the chain.
The request · illustrative
Send a revised purchase order to a supplier.
- Asking
A purchasing agent, owned by the operations lead, acting for a named buyer.
- Permission
It may read the order and draft the message. Sending to a supplier is sensitive, so it is routed for review.
- The model sees
“[PERSON_A] asks to revise the order.” The buyer's name is pseudonymised before the model sees it.
- Approval
The operations lead reads the draft and approves the send.
- Record
Request, policy, redaction, approval and result are recorded together, linked to the entry before.
Sent once a person approved it, with the whole path on record.
An illustrative request. Nothing on this page calls a model or enforces a policy; the privacy gateway belongs to a Lumen Intelligence deployment.
CONTROLS BY AREA
What is built, what is coming,
what we agree with you.
Every control carries its status and, where a product provides it, the product. Filter by status to see what you can rely on today and what belongs in your contract.
Every control, with its status.
Identity and access
Who or what is acting, for whom, and what it may reach.
- Agents, models, tools and non-human identities mapped to their owners
- The access each workflow needs, understood before it is granted
- Context gathered only within each person's own permissions
- An evidence-backed picture of people, groups and accounts from your directories
- Sign-in through your identity provider, and how agent identities are provisioned
Data protection and privacy
What stays where it is, and what a model is allowed to see.
- Personal data stays in the appliance
- Sensitive values removed or pseudonymised before a model sees them, failing closed
- One shared folder between a space and your Mac; the rest is not mounted
- Mail an agent receives is treated as untrustedLumen Mail is in pilot.
- Share links with an expiry, an optional password and a download limit
- Encryption, key management and where your data resides
Model choice and routing
Which model answers, where it runs and what reaches it.
- Requests routed to the providers and models suited to the task
- An existing endpoint connected, or a model deployed on infrastructure you control
- Fallback behaviour defined in advance
- Policy applied to model requests and tool actions
- Which third-party model providers are used, and their terms for your data
Human oversight
Where a person decides, and how an agent is stopped.
- Sensitive operations routed for review, with the reason an action was allowed or denied
- Human approvals composed into the workflow
- Take over a space at any time; agent input pauses while you do
- A policy gate before tools run that fails closed, and that an agent cannot edit
- Anything that would affect existing mail stops for a person to decideLumen Mail is in pilot.
Audit and evidence
The record your security and risk teams can follow.
- Decisions connected to their inputs, policies and approvals
- A hash-chained audit log
- The sources, approvals and actions behind each result
- A receipt of what changed in each pull request
- Signals followed through to the decision and action they led to
- How long records are kept, and export to your own security tooling
Deployment and isolation
Where each product runs, and what separates it.
- On a person's own device
- A virtual machine on a Mac with Apple Silicon
- Customer-hosted on a Linux VM or Kubernetes, or fully air-gapped
- Outbound links mutually authenticated, and yours to switch off
- Deployment boundaries you choose
- Learning from everyday activity, with consent
- Hosting, tenancy and isolation for a platform deployment
Secure development and release
How a change is proven before it reaches anyone.
- Evaluation on representative examples before release
- A/B experiments and evaluation results compared before a version is promoted
- Configured compliance requirements checked before promotionA check supports review; it does not establish compliance by itself.
- A path back to a previous release
- Instructions, tools and context versioned together
- Our own secure development, testing and vulnerability handling, documented for your review
THE QUESTIONS YOUR SECURITY TEAM WILL ASK
Hard questions.
Straight answers.
Asked the way a sceptical reviewer would ask them. Where the answer depends on your deployment or your contract, we say so rather than promise it here.
Data
Where is our data stored and processed?
It depends on the deployment, and the plan above draws each one. Lumen works on a person's own device. Lumen Spaces runs as a virtual machine on your Mac. Lumen Intelligence is hosted by you, on a Linux VM, Kubernetes or fully air-gapped, and personal data stays in the appliance. Platform deployments run on infrastructure you choose. For every deployment, the data map, hosting location and region are agreed with you and written down before anything is connected.
AvailableAgreed with youIs our data used to train models?
On-device and customer-hosted designs keep your data with you: Lumen on the person's own device, Lumen Intelligence inside your infrastructure, where a model beyond it sees pseudonyms rather than the values themselves. For any other flow, including a third-party model provider's terms, how your data may be used is agreed in your contract before it is enabled.
AvailableAgreed with youModels
Which models do you use, and which third-party providers see our data?
The ones you choose. Bridge connects providers, routes each request to the model suited to the task and can use a model deployed on infrastructure you control. Mesh applies policy to model requests. Any third-party provider in a deployment, and its terms for your data, is named and agreed with you during procurement.
AvailableAgreed with youAccess
How do agents get identities and permissions? Do you support single sign-on?
Mesh maps agents, models, tools and non-human identities to their owners, and the access a workflow needs is understood before it is granted. Lumen gathers context only within a person's own permissions. How people sign in through your identity provider, and how agent identities are provisioned, is agreed with you and configured during the engagement.
AvailableAgreed with youCan your team access our data?
In on-device and customer-hosted deployments your data stays in your environment, so our access is whatever you grant; an air-gapped appliance has no outbound link at all. For other deployments, who may access what, and how that access is recorded, is agreed with you and written into the contract.
AvailableAgreed with youEvidence
What is logged, and can we see the audit trail?
Mesh connects each decision to its inputs, policies and approvals, and can explain why an action was allowed or denied. Lumen Intelligence keeps a hash-chained audit log, so an altered entry breaks the chain. Dex keeps a receipt of what changed in each pull request. How long records are kept, and whether they are exported to your own security tooling, is agreed with you.
AvailableAgreed with youIncidents
How are incidents handled, and when would we be told?
Incident response and notification are agreed with you and documented before go-live: who is told, how, and what evidence is shared. This page does not state response or notification times. They belong in your contract, where you can rely on them.
Agreed with youHow do we report a vulnerability?
Write to sales@swfte.com, through the contact page, with what you found and how to reproduce it. Please keep the details private while we look into it; we will reply to agree the next steps with you.
Exit and continuity
What happens to our data if we leave?
Where data stays with you, on a person's device or in your own infrastructure, it is already in your hands when the engagement ends. For platform deployments, retention, export in usable formats and deletion on exit, including how deletion is confirmed, are agreed in your contract.
AvailableAgreed with youWhat about business continuity and recovery?
Bridge lets you define fallback behaviour and keeps a path back to a previous release. Backup, recovery and continuity arrangements for your deployment are agreed with you and documented; this page does not quote recovery objectives.
AvailableAgreed with youAssurance
Which certifications and independent audits do you hold?
No certification or independent audit is claimed on this site. The security documentation that applies to the deployment you are considering, and the evidence your procurement process requires, is shared during procurement. Request it through the contact page.
Agreed with youCan our security team test the deployment?
Whether and how your own team tests the deployment, its scope, timing and how findings are handled, is agreed with you during procurement.
Agreed with youWho else is involved in delivering the service?
Any third party involved in your deployment, including a model provider, is named for you during procurement. This page does not publish a list.
Agreed with youRegulation
How do the EU AI Act and GDPR apply?
It depends on what the system does and who does what. Which obligations apply, and each party's role under GDPR, are worked through with you in discovery, alongside your own legal advisers. A configured compliance check in Bridge supports review; it does not establish compliance by itself.
Agreed with youWHEN YOU ARE READY
Bring your security team
into the first conversation.
We share the documentation that applies to the deployment you are considering, draw your data map with you and agree the controls before anything is connected.