Security built into how we work.
Artifact builds software and AI-enabled systems for organizations that trust us with important business processes and data. Security, privacy and responsible data handling are considered throughout how we design, build, deploy and operate software.
SOC 2 Type II In progress Preparing for audit. Not yet audited, and no report exists.
Security isn’t an add-on. It’s part of the architecture.
Most security incidents involve data a company did not need to be holding, in a system it did not need to have built. So the earliest decisions in a project are the ones that matter most: what the system will handle, what it can avoid handling at all, and which parts are better served by infrastructure built and maintained by specialists.
Payment details are the clearest example. A system that routes payments through established payment infrastructure, and never stores raw card details itself, removes an entire category of risk rather than defending against it. The same reasoning applies to authentication, file storage and email delivery.
That reasoning has a limit worth stating plainly: choosing a reputable provider does not make a system secure. How it is configured, what it is permitted to reach and what is built around it remain our responsibility, and are where most of the real work sits.
How we work, and how far along each part is
Each area below carries its own status, because they are not all at the same stage. Where implementation depends on the system being built, it says so rather than implying one standard applies to every engagement.
- Developing
Access control
Access to source control, hosting and production resources is kept to the people who need it, and granted through the providers’ own identity and permission systems rather than shared credentials. The underlying principle is least privilege; writing it down as a reviewable policy is part of the compliance work below.
- In practice today
Secure development
Security is considered during development rather than inspected for afterwards: input is validated and escaped before it is used, secrets live in environment variables and never in the repository, and every change to production arrives through version control and an automated deploy, so what is running can be traced to the commit that put it there.
- Developing
Vulnerability management
Dependencies and application behaviour are reviewed for known issues, and we keep the dependency surface deliberately small to reduce what has to be watched. Automated scanning on a fixed cadence, with a defined response window, is being put in place rather than already running.
- In practice today
Data protection
Traffic to our site and services is served over HTTPS, with HSTS set on production responses. On client systems, the safeguards that apply to stored data depend on the architecture and the provider chosen for that system, and are decided during implementation rather than assumed here.
- Developing
Monitoring
Deployments, availability and errors are visible through our hosting platform. Broader monitoring for abnormal or security-relevant behaviour is defined per system, according to what that system does and what the customer requires, and is an area we are formalizing.
- Developing
Backups and recovery
Our own site holds no application database: it is statically generated and can be rebuilt from source control. For client systems that do hold data, backup frequency and recovery expectations are set with the customer during implementation, because a recovery target is a business decision before it is a technical one.
Built on trusted infrastructure.
We use established providers for the parts of a system where specialist operators do a better job than we would, and where rebuilding would mean holding sensitive data we have no reason to hold. These are the providers behind Artifact’s own site and operations.
-
Vercel
Hosting, deployment and analytics
Serves the site, runs the form endpoints, and provides cookieless usage analytics.
-
GitHub
Source control and change history
Holds the codebase and the record of every change that reached production.
-
Resend
Transactional email
Delivers contact enquiries and Insights subscriptions. Processes the details you type into those forms.
Client systems are built on their own stacks, chosen for what that system has to do and for the customer’s existing environment and requirements. We will tell you exactly which providers a proposed system would involve, and what each would process, before it is built.
Using an established provider transfers operational burden, not accountability. Every provider remains part of our vendor-risk picture, and the responsibility for how a system is configured and what it exposes stays with us.
Responsible AI starts with responsible data.
We build AI-enabled systems, which means customer information can end up travelling further than it would in conventional software. These are the decisions we make deliberately rather than by default.
-
Send less
The first question about any AI feature is how little customer data it can work with, not how much it could be given.
-
Scope what the model can reach
What a model or agent is able to read is defined deliberately, so capability does not quietly become broad access to everything a system holds.
-
Protect credentials
Provider keys are held as environment secrets on the server side, never embedded in client code or committed to a repository.
-
Decide retention on purpose
How long prompts, outputs and intermediate data persist is a design decision for each system, made with the customer rather than inherited from a default.
-
Evaluate the provider
Model providers differ in what they retain, where they process it and what their terms allow. That evaluation belongs in the design of a system, not in a blanket promise on a marketing page.
-
Keep a person in the loop
Where a workflow is sensitive or irreversible, it is designed so a person approves the consequential step rather than discovering it afterwards.
-
Separate environments
Customer environments and data are kept apart where the architecture allows it, so one system’s context cannot become another’s.
AI should expand what software can do without unnecessarily expanding who can access your data.
One thing we will not tell you in the abstract: whether a given provider trains on your data. That depends on the provider, the plan and the configuration chosen for a particular system, and it changes. It is something to establish and document while designing that system — and we would rather confirm it for your architecture than make a promise here that covers providers we have not selected yet.
Your data remains your data.
Customer data belongs to the customer. We hold it to do the work we have been engaged to do, we keep internal access to the people doing that work, and we return or remove it when an engagement ends and the customer asks.
This site itself collects very little. It is statically generated with no database and no accounts. If you send the contact form or subscribe to Insights, the details you type reach us by email through our delivery provider; usage analytics are cookieless and aggregated, which is also why you were not asked to dismiss a cookie banner.
Where a system we build processes personal information, the processors involved are identified during design rather than discovered later.
Building toward independent assurance.
Artifact is formalizing the policies, controls, evidence and operational processes that support independent security assurance. This is where each part genuinely stands today.
| Area | Status | What that means |
|---|---|---|
| Secure development practices | In practice today | Version-controlled change history, automated deploys, server-side validation and escaping, secrets held outside the codebase. |
| Security program documentation | Developing | Writing down what we already do, in a form that can be reviewed and evidenced. |
| Vendor and subprocessor management | Developing | A maintained inventory of providers, what each one processes, and a review before new ones are introduced. |
| Vulnerability management | Developing | Moving from periodic review to scheduled scanning with a defined response window. |
| Incident response | Developing | A documented procedure for detection, containment, customer notification and review. |
| SOC 2 Type II | In progress | Preparing the policies, controls and evidence an independent audit would examine. No audit has been performed and no report exists. |
| Independent penetration testing | Planned | Not yet performed. When it happens, this page will say when and by whom. |
In practice today means it is how we work now. Developing means it is real but not yet written down and evidenced to a standard an auditor would accept. Planned means it has not happened yet. We would rather you read an accurate status than an impressive one.
Security documentation
As our security program develops, documentation will be made available to qualified customers under NDA as part of a security review. The set below is what that documentation is being built toward — it is a roadmap, not a library, and nothing here is offered as a download today.
- Security overview
- Information security policy
- Access control policy
- Incident response policy
- Business continuity and disaster recovery
- Vulnerability management policy
- Vendor and subprocessor information
- Data processing addendum
Security documentation is available or being developed as part of our compliance program. If your review has specific requirements — a questionnaire, a DPA, evidence of a particular control — tell us what you need and we will tell you what we can provide today and what is still being written.
Have a security requirement? Let’s talk.
Enterprise systems don’t all carry the same risk. If your organization has specific security, privacy, procurement, infrastructure or compliance requirements, we’ll discuss them with you before implementation rather than after.