Security & responsibility
Trust, by design.
The systems we build carry real responsibility. Our commitment is to consider security, data protection, and human judgment from the first architectural decision onward.
A shared responsibility
Keep judgment in the system.
Establish responsibility, meaningful review, and clear boundaries for consequential AI actions.
Conceptual study · Not a production diagram
Security commitments
Responsibility, from the foundation up.
Security belongs in the decisions we make—not just the systems we deliver.
We commit to treating security as a shared responsibility across AI architecture, software development, and the way we work with clients. That means considering risk early, protecting entrusted information, and making deliberate, accountable decisions as systems evolve.
Design around the risk.
We commit to considering the intended use, sensitive data, trust boundaries, and potential consequences of a system before selecting an approach. Security requirements and trade-offs should be discussed with the client, documented appropriately, and revisited when the scope changes.
Give access a clear purpose.
We commit to favoring access limited to what a person, service, or agent needs for its role. Authentication, permissions, privileged actions, and the removal of access should be considered in the design and agreed responsibilities for each engagement.
Treat entrusted information with care.
We commit to considering data sensitivity throughout collection, use, storage, transfer, retention, and disposal. Appropriate encryption, environment separation, and credential handling should be chosen for the system’s risks and requirements, rather than assumed from a product label.
Keep changes accountable.
We commit to making code changes traceable to their purpose and review. Relevant testing, approvals, review feedback, and release decisions should be recorded alongside the change so that its history can be understood, not reconstructed from memory.
Consider the whole supply chain.
We commit to considering the security and data-handling implications of dependencies, infrastructure, and AI providers. Service selection should account for the engagement’s requirements, the information involved, and the responsibilities that remain with us and the client.
Plan for concerns, not just success.
We commit to considering how security concerns will be raised, assessed, and coordinated with the appropriate parties. Incident responsibilities, escalation routes, and any notification obligations should be established for the engagement under its applicable agreements.
Responsible AI
Intelligence needs judgment.
AI creates new possibilities. It also asks more of the people who design and use it.
Define the boundaries.
We commit to clarifying what an AI system is for, where it should not be used, and how uncertainty or failure should be handled. Capabilities should be evaluated against that intended use.
Keep people accountable.
We commit to designing for meaningful human judgment over consequential actions. Review, approval, and escalation points should reflect the potential impact—not simply what can be automated.
Use data with authorization.
We commit to considering whether information is appropriate and authorized for its proposed AI use. Data access and disclosure should be limited to the purpose agreed with the client.
Constrain agent authority.
We commit to considering scoped tool permissions and approval boundaries. Prompts, retrieved content, and model outputs should be treated as untrusted input—not as permission to access data or take action.
Evaluate beyond the demo.
We commit to considering reliability, misuse, harmful or biased outputs, and failure modes in evaluation. Relevant limitations and the need for further testing should be communicated rather than hidden behind a successful example.
Choose providers deliberately.
We commit to evaluating provider suitability for the use case, including available security settings and data-handling terms. A provider’s claims do not substitute for evaluating the system built around it.
Software delivery
Considered at every step.
Our commitment is to make changes understandable, reviewable, and accountable throughout an engagement.
Design
Understand the data, intended use, and risk. Agree on security requirements, responsibilities, and important architectural decisions.
Build
Keep changes purposeful and traceable. Consider dependency risks, credential handling, and separation appropriate to the engagement.
Review
Record relevant code review, test results, feedback, and approvals. Address material concerns before a release decision.
Release
Make release decisions reviewable. Provide an appropriate handover covering known limitations, operating responsibilities, and agreed next steps.
Assurance & transparency
Clear about where we stand.
Trust depends on being precise about what a public statement does—and does not—establish.
SOC 2
We are working toward SOC 2.
This page is a statement of our commitments, not an independent assurance report. Working toward SOC 2 does not mean that an examination has been completed or that a report has been issued.
For current information relevant to your evaluation, please contact our team. We can discuss the scope of your request and what information can appropriately be shared.
Engagement-specific obligations are governed by the applicable agreements, including any agreed security requirements. This page does not replace or amend those agreements.
A continuing conversation
Let’s talk about trust.
Have a security requirement, a due-diligence question, or a concern? Start a conversation with our team.
What is your SOC 2 status?
We are working toward SOC 2. We are keeping our public status general. This page does not claim a completed examination or an issued report. Contact our team for current information relevant to your requirements.
Can we discuss project-specific security requirements?
Yes. Raise your requirements during scoping so that the controls, responsibilities, evidence, and contractual obligations can be evaluated and agreed. Do not assume that a particular compliance requirement is met solely because it appears in a public commitment.
How will an AI system use our data?
That depends on the system, providers, and agreed configuration. Model training, retention, processing locations, and permitted data use must be established for the engagement. Ask us to clarify those arrangements before providing sensitive information.
How can we request more information or raise a concern?
Use our existing contact page to describe the nature of your inquiry without including sensitive information. We can then discuss an appropriate channel and what information can be shared. This page does not promise the availability of a particular document or report.