Trust — how we build AI

How noorflows builds AI you can trust: it proposes and you approve, it answers from your data, and you own it — proved by a rebuild from the handover pack.

The short version: an AI agent that can move money, delete records, or send things to your customers without a human saying yes is a liability, not a feature. Every agent noorflows builds proposes, and you approve — for anything that costs money and anything that cannot be undone. And you own it: the workflows, the prompts, the runbook and the keys live on your infrastructure, not rented back to you per ticket. Before we close an engagement, an engineer who did not build it stands your system up from the handover pack alone. This page explains exactly what all of that means and how your data is handled.

Reviewing us as a supplier? Start at section 13 — the work we refuse, who carries which duty under the EU AI Act, and which questionnaire lines are ours rather than the model provider's.

This page covers AI agents and automations noorflows builds for clients. For how the noorflows.com website itself handles data (analytics, lead forms, payments), see the Privacy Policy.

1. The approval gate — it proposes, you approve

Two kinds of action are approval-gated. Anything that moves money or makes a commitment — a refund, a discount, a cancellation, an outbound email, a write to your store or CRM. And anything that cannot be undone — deleting records, dropping a table, overwriting a file, revoking access. The agent prepares the action and the evidence behind it; a human approves before anything happens.

The second half is there because of a real failure. In April 2026 an AI coding agent deleted a company's production database and its backups in nine seconds. No money moved, so a gate built only around money would have let every step through. Destructive and irreversible actions are gated on the same footing as money, and backups are kept where the agent cannot reach them.

This is the direct, recommended mitigation for what the OWASP Top 10 for LLM & Agentic Applications calls Excessive Agency — which rose from sixth place to third in the 2026 edition. Agents are given the minimum authority to act, and the consequential decisions stay with a person. It also contains the blast radius of any prompt-injection attempt — even a successful manipulation cannot, on its own, execute a gated action.

2. Grounded answers — it does not invent facts

Agents answer from real data and your own documents — order records, your knowledge base, your policies. When the answer is not in the source data, the agent says so and escalates to a human rather than guessing. "Where is my order?" is answered from the actual order status, never a plausible-sounding fabrication.

3. AI disclosure

Customer-facing agents identify themselves as AI and offer a clear path to a human. This aligns with the EU AI Act transparency obligations for AI systems that interact with people (in force from 2 August 2026), and it is simply how trustworthy support should work.

4. Prompt-injection resistance

Untrusted input (customer messages, scraped pages, documents) is treated as data, not instructions. Agents run with scoped, least-privilege tools, so even a crafted message cannot expand what the agent is allowed to do. Combined with the approval gate above, this addresses the top entries in the OWASP LLM risk list — prompt injection, sensitive-information disclosure, and excessive agency.

5. Data & PII handling

We follow data minimization: an agent is given only the data it needs for the task at hand. Where personal data is involved, identifying details are minimized or redacted before they reach the model wherever the workflow allows, and sensitive fields are kept out of logs. Customer data is processed to answer the request — it is never sold, and it is not used to train third-party models.

6. Scoped, rotated credentials — you hold the keys

Integrations use per-engagement, least-privilege API credentials — never shared, broad, or long-lived "god keys." Keys are scoped to exactly what the workflow needs, rotated, and stored in your own secret store. This follows current non-human identity (NHI) security guidance for AI agents. Because the system is yours, you can revoke any credential at any time.

7. Decision trail

Sensitive actions — what the agent proposed, who approved it, and what happened — are logged, so there is an answerable record of every decision. That record is what turns "a person approves" from something we say into something you can check.

8. You own it — no lock-in

At the end of an engagement you hold the whole system. It runs on your own infrastructure, including in your own region where data residency requires it, and we can look after it for you afterwards. There is no per-ticket rent and no vendor lock-in — the opposite of pay-per-resolution AI support.

The handover pack is the same every time:

  • The workflow definitions and any code, in a repository or account in your name, with the history intact.
  • A written runbook: what each part does, how to deploy it, how to roll it back, how to restore it, and what to do when it breaks.
  • The checks it has to pass, and what they returned on the day we handed over.
  • The environment and configuration — every setting the system needs to run, written down rather than remembered.
  • Any tools we wrote for you along the way.
  • The credentials, issued by you and revoked on our side when the engagement closes.
  • Admin access to everything it runs on — the platform, the data store, the domain records, and whatever watches it.
  • On a migration, the field mapping — the document that says what became what.

We check the handover rebuilds, before you sign it off

A pack that has never been used is a pack nobody has tested. So before we close an engagement, an engineer who did not build your system takes the pack above and nothing else, and stands the system up from it in a clean environment. If they cannot, the pack is wrong and we fix the pack. You get the result in writing, including anything that could not be stood up and why.

What it covers and what it does not, so the promise is checkable rather than reassuring: it runs on the parts we built and handed over; it is done within ten working days of the pack being complete; and it needs you to provide working credentials for anything the system talks to. It does not cover third-party services that have changed since delivery, data you have altered, or work outside the signed scope. Where the rebuild fails on something that is ours, we fix it at no charge until it stands up — that is the remedy, and it is the whole remedy.

Software escrow exists because "handed over" is so often untrue. Firms pay a third party to hold a copy of the code, and pay again to test that the copy can actually be rebuilt. Yours is in your own account from the first delivery, so there is nothing to escrow — and we run the rebuild check ourselves rather than asking you to buy it.

9. Subprocessors (for AI builds)

Two different things get called a subprocessor, and only one of them is ours.

Where you hold the account, the provider is yours, not ours. If your system calls a model on your API key, or writes to a platform you pay for, that provider is your own processor and belongs on your list. We tell you which ones your build reaches so you can put them there. We do not stand between you and them, and we take nothing from what you pay them.

Where we hold the key to deliver the work, it is ours, and the whole list for your build goes in your engagement documents. Transfers outside the EEA or the UK run on the Standard Contractual Clauses — including to Anthropic, which is not certified under the EU–US Data Privacy Framework. Typically:

  • Anthropic (Claude) — language model. United States. Anthropic does not train on data sent through its API.
  • n8n — the orchestration layer. Runs on your own infrastructure or on n8n's cloud, in the region you choose. You hold it, not us.
  • Cloudflare — edge hosting and delivery. Listed as active on the EU–US Data Privacy Framework register, and on the Swiss–US framework and the UK extension.
  • An open-weight model on a US host, where a job is high volume and low stakes — for example Amazon Bedrock or a comparable US provider. The host is the subprocessor; the model publisher receives nothing. The decisions that need judgement stay on Claude.

We do not send client data to deepseek.com, and we will not. Italy's data protection authority ordered the two DeepSeek companies to stop processing Italian users' data in January 2025; Germany's Berlin authority found the transfers to China unlawful and reported the apps to Apple and Google. DeepSeek publishes no Standard Contractual Clauses and states that it stores personal data in China. Where an open-weight Chinese model is the right engineering choice, it runs on a Western host under that host's terms, and it is named as such above. If you would rather it did not run at all, say so at scoping and it will not.

We tell you in writing before adding or replacing a subprocessor we hold, with thirty days' notice, so you can object before it starts. Subprocessors used by the noorflows.com website itself are listed in the Privacy Policy.

10. Data residency

Self-hosted components (n8n and your data store) can run in the region you choose. Model inference is processed in the provider's own regions, which for the providers listed above means the United States. If you have specific residency requirements (for example, keeping EU customer data in the EU), tell us up front and we will scope the architecture — including which steps may run on a self-hosted or open model inside your own region — to meet them.

11. Standards we build to

  • OWASP Top 10 for LLM & Agentic Applications — approval gating, least-privilege tools, input handling, and logging map to these controls.
  • EU AI Act transparency (AI disclosure; effective 2 August 2026).
  • GDPR / CCPA data-subject rights — see the Privacy Policy.
  • Non-human identity (NHI) credential hygiene — scoped, rotated, least-privilege keys.

12. Backups, encryption & disaster recovery

On the infrastructure we operate ourselves, databases and configuration are backed up nightly, AES-encrypted before they leave the server, and pushed off-site. Backups are watched by a dead-man's-switch monitor that alerts on any failure or missed run, and restore is tested — a timed restore drill in July 2026 recovered all data intact (data-restore RTO ~13 seconds). Secrets are encrypted at rest with SOPS/age and never stored in plaintext in version control. The server itself is key-only SSH behind a default-deny firewall, and its build is codified as infrastructure-as-code for reproducible recovery.

12A. If something goes wrong

If we find a security problem affecting your system or your data, we tell you without undue delay from the moment we find it, in writing, in plain words. You get what we know, what we do not yet know, what we have already done, and what we need from you. Then we help you meet your own deadlines — under the GDPR it is you, not us, who has 72 hours to tell a regulator, and we would rather be the reason you make that than the reason you miss it.

We do not publish an hour, and we would rather say why than leave a number lying around. No law puts one on a supplier. The hours you have seen in other vendors' pages come from buyers' contracts — commonly 24 or 72 hours — and if you need a specific one, write it into ours and we will meet it. A number invented for a web page is a promise to nobody.

Telling you about an incident, or helping you deal with one, is not an admission that it was our fault. Where it was, we will say so in the same message.

13. Work we refuse to build

Some jobs we turn down. Naming them is more useful than a list of principles, because you can hold us to a refusal.

  • A system that makes the final call on a person's job, credit, housing, insurance or schooling, with no human able to change it.
  • A system that imitates a real person's voice, face or writing without that person's consent.
  • A system that claims to be human when someone asks whether they are talking to a machine.
  • A system that sorts or scores people by characteristics they cannot change.
  • A system with no way to stop it.

If a job needs one of those, we say no and explain why. It has happened before.

14. Who carries which duty

You run the system under your own name, so under the EU AI Act you are usually the provider and we are the contractor who built it. The transparency duties that started on 2 August 2026 — telling people they are speaking to a machine, labelling synthetic media, and marking generated output so software can detect it — sit with you, not with us.

Our job is to make them easy to meet: to build the disclosure in, to mark what needs marking, and to hand you the records that show it was done. Article 50 applies from 2 August 2026 whenever a system was first placed on the market. A grandfathering rule for systems already on the EU market before that date, which would move the marking deadline to 2 December 2026, has been proposed and is not yet law — we will tell you what yours needs either way rather than let you plan on a proposal.

From 1 January 2027, Colorado places a duty on us directly. Where we supply the technology behind a decision that materially affects someone's access to education, employment, housing, lending, insurance, health care or an essential government service, you get documentation of what it is for, what categories of training data feed it, what it cannot do, and how to use it and review it properly. We also tell you when we materially change it. We keep those records for three years, and so must you.

Said plainly, because it is still moving: that law replaced an earlier Colorado act, a federal court suspended its enforcement in April 2026, and the state's own rules are in consultation until 26 October 2026. We build to it anyway — the documentation costs us nothing to produce and you would need it whichever way the case lands.

15. What is ours, and what is the model provider's

Send us a security questionnaire and some of it will not be ours to answer. The AI sections of the standard forms are written as though the supplier trained the model. We did not. We answer what is ours and tell you plainly which lines belong to the model provider, so nothing is left looking answered when it is not.

  • Ours: what the system may reach, what it hands to a person, what it writes to a log, how you stop it, who holds the keys, where your data goes, and what we tested before handover.
  • The model provider's: how the model was trained, what went into it, how its weights are handled, and what it does on their side of the connection.

Where we test, we report precision and recall — at record level and at entity level — and we show the working. We do not report a single quality score, because on data where most records are already fine, doing nothing scores well and means nothing.

What we do not claim

noorflows is an independent firm and holds no SOC 2 or ISO 42001 accreditation. We build to those control principles and can support your own compliance and vendor-review process. If your procurement requires formal accreditation, tell us and we will be straight with you about what we can and cannot meet today.

Data Processing Agreement & security review

A Data Processing Agreement (DPA) is available on request, and we are happy to complete a reasonable security questionnaire before an engagement. To save you a round-trip, our pre-filled security questionnaire (PDF) answers the common vendor-review questions up front. Email hello@noorflows.com for a DPA or anything not covered.

Contact

Questions about how an agent decides and who approves it, how your data is handled, or to request a DPA:

Noorflows LLC
hello@noorflows.com

That is how it works. Here it is running.

Seven named clients, each with the things their system refuses to do. Every one opens in a browser — no form, no email, no call first.

See the work Request a DPA or review