Security & trust
Define what information AI can use, where it can run and when a person needs to decide. Keep the policy and the record close to the work.
Detection and tokenisation run inside your environment, before anything crosses.
Only destinations you have approved are routable by policy.
Each crossing is evaluated against explicit, versioned policy, not convention.
Requests carry who is asking, from where, under which role.
Encrypted transport and storage, with per-environment isolation.
Consequential actions can require a named person to approve before execution.
A detailed audit trail records each decision; crossings can be reviewed after the fact.
Outputs can be linked to the sources that support them, or flagged when they are not.
You decide what the boundary keeps, for how long, and where.
A reviewable decision
Information treatment, route selection and human approvals belong in the same story. Explore the record a reviewer can use to follow the decision.
Read an example decision recordShared responsibility
Information controls work alongside your people, infrastructure and security practices. Architecture and deployment documentation are part of the conversation.
Restricted identifiers, references, and codewords leaving with an AI request.
Requests reaching models or tools outside your allowlist.
Crossings and actions that leave no reviewable record.
Generated claims with no link to the evidence behind them.
A compromised workstation or host sits before the boundary. Endpoint and OS security remain yours.
A person or administrator with legitimate access acting outside monitored paths.
BoundSense enforces the rules configured for it. Incorrect or overly permissive policies can still allow unsafe behaviour and need operational review.
Input controls, route restrictions, approval gates, and audit trails reduce exposure. No boundary eliminates every adversarial prompt or downstream tool-execution risk.
The boundary governs what a model sees and where it runs, not whether its answer is right.
The supply chain of the models and provider infrastructure you choose to run is a shared responsibility.
Benchmarks measure the evaluated scope only; they do not establish general performance.
A small model clearing one task threshold implies nothing about other tasks.
Training and evaluation can inherit or amplify dataset defects and leakage; data quality remains a shared responsibility.
Running locally reduces egress exposure but does not by itself make a system secure.
Escalating to a larger external model widens the crossing; fallback paths need the same policy scrutiny as primary routes.
Axon conversation connectors depend on external platform controls and availability.
People handling escalated conversations remain part of the trust boundary.
Keeping raw examples and corpora in place narrows what crosses. It is not secure aggregation, differential privacy, confidential computing or zero-knowledge protection, and the metrics or excerpts that do cross can still carry inference risk.
A global metric can pass while a required environment fails. Distributed evaluation is designed to keep that failure visible and hold promotion; an aggregate on its own is not a release decision.
Private distributed evaluation and governed distributed retrieval are roadmap architecture. Neither is implemented, and neither is available in pilots today.
A first conversation
Tell us the task and where the information must stay. We'll show a relevant example and discuss whether a scoped pilot makes sense.
Request a demopilot@kordane.ai