What we do with your data, and what we don't.
We hold no formal certification. Rather than leave that unsaid, here is exactly how engagements are structured, where data sits, who can reach it, and which requirements we cannot meet.
- Your tenancy
- No training on your data
- Named access
- Exit designed in
- 01
Your tenancy, not ours
Repositories, cloud accounts, databases, domains and ad accounts are created in your name and billed to you from the first commit. Production client data lives in your infrastructure under your access controls, which means your existing compliance posture governs it rather than ours.
- 02
Least access, time-boxed
We ask for the narrowest role that lets the work proceed, scoped per environment. Access is requested when it is needed and handed back at the end of the engagement — we will send you the revocation checklist rather than wait to be asked.
- 03
Secrets never enter the repository
Credentials live in your platform's secret store and are referenced by environment variable. Nothing secret is committed, pasted into an issue, or shipped in a client bundle. Public keys and publishable tokens are the only values that appear in code.
- 04
Your data is not training data
We do not train models on your data, and we do not use it to improve anything we sell to anyone else. Where a model provider is in the path, we configure the enterprise or API tier whose terms exclude training, and we will show you that configuration.
- 05
Subprocessors are named up front
Anything that touches production is listed before it is introduced, with its purpose and its data-residency position — typically a hosting platform, a database, a model provider, a transactional email service and an analytics endpoint. If one is unacceptable to you, we design around it rather than argue about it.
- 06
Human gates on irreversible actions
Agent systems get scoped authority and an audit trail. Anything that spends money, sends on your behalf, deletes, or publishes requires a human decision. That is an architectural constraint, not a setting somebody can switch off later.
- 07
A small, senior access surface
There is no offshore bench and no rotating pool of contractors. The people with access are the people doing the work, and you will know their names. This is the whole reason a firm this size can be trusted with production credentials.
- 08
Exit is designed in
Because everything is already in your accounts, ending an engagement is an access revocation rather than a migration. Runbooks, architecture notes and a working local environment are produced throughout — not assembled at the end.
What we can’t do for you.
We are not certified
No SOC 2, no ISO 27001, no HITRUST. If your procurement requires an audited attestation from your vendor, we will not pass it, and you should know that before the first call rather than after the third. Say so early and we will tell you honestly whether the work can be structured so that your certified tenancy is the one under audit.
We are not your compliance function
We build to the control set you give us and we will flag what we think is missing, but we do not write policy, sign attestations, or advise on regulatory interpretation. Where a category demands it — health, financial services, legal — the review gate belongs to your counsel and we build the gate into the system so it cannot be skipped.
We do not take custody of regulated data by default
Engagements are designed so that protected data stays in your environment. If a piece of work genuinely requires us to process it, that gets its own agreement, its own scope, and its own controls before anything is built.
Asked by every technical buyer.
- Are you SOC 2 or ISO 27001 certified?
- No. We hold no formal security certification and we do not imply otherwise. Because engagements run inside your cloud accounts under your access controls, the audited environment is usually yours rather than ours — but if your procurement requires an attestation from the vendor itself, we will not meet it.
- Will our data be used to train models?
- No. We do not train on client data and we do not use it to improve anything sold elsewhere. Where a model provider sits in the request path we configure the tier whose terms exclude training, and we will show you that configuration rather than assert it.
- Who on your side can access production?
- The people doing the work, and you will know their names. There is no offshore bench and no contractor pool. Access is scoped per environment, requested when needed, and revoked at the end of the engagement against a checklist we hand you.
- Where does our data live?
- In your infrastructure, in the region you choose. Repositories, databases, cloud accounts and domains are created in your name from the first commit, so data residency is a decision you make and can change without involving us.
- What happens to access when the engagement ends?
- You revoke it. Because nothing was ever in our accounts, ending an engagement is an access change rather than a data migration. We supply the revocation checklist, the runbooks and a working local environment as part of handover.
- Can agents take actions on our systems?
- Only within a scope you define, with an audit trail, and never for anything irreversible. Spending, sending, deleting and publishing all require a human decision. That boundary is built into the architecture rather than configured on top of it.
Reviewing us as a vendor? Send your security questionnaire to t@moher.ai before the first call. We would rather fail your screen early than waste a month of yours. See also how the firm operates.
Still need to talk to someone.
Send the questionnaire, the architecture, or just the constraint you're worried about. We answer inside one business day.
Or write directly — t@moher.ai