Skip to main content

Security & data handling

Security questions belong in the solution design.

Security is not a review at the end. These are the questions NeuronFlow works through while a workflow is being designed, so the answers are built in rather than retrofitted. This page is maintained by NeuronFlow and is not an independent audit, certification, or attestation.

Tier one

Questions addressed during design

Each of these is answered for the specific workflow, with your team, and written down before build. We evaluate and document answers — we do not certify them, and we do not claim controls that have not been verified in your environment.

  1. Question 1

    What data is needed?

    The minimum categories a workflow requires, and what is deliberately excluded.

  2. Question 2

    Where does it come from and where may it go?

    Sources, destinations, regions, and any third party that touches the data in the flow.

  3. Question 3

    Who may access the workflow?

    Identity, roles, and which people or teams may trigger, view, or change it.

  4. Question 4

    Which tools and actions are allowed?

    The bounded set of systems and operations available, and what remains read-only.

  5. Question 5

    What is logged?

    Inputs, retrieved sources, outputs, actions, and reviewer decisions, to the extent your policy permits.

  6. Question 6

    How are secrets managed?

    Where credentials live, who can rotate them, and how they are kept out of prompts and logs.

  7. Question 7

    How is output tested?

    An evaluation set from your real cases, agreed acceptance criteria, and sampling after launch.

  8. Question 8

    What happens on failure or incident?

    Fallback behaviour, escalation route, shutdown path, and who is notified.

  9. Question 9

    How are vendors and model providers evaluated?

    What each provider does with data, contractual terms, and the alternatives considered.

  10. Question 10

    How is the system changed or retired?

    Change control, version history, ownership on handover, and a defined decommission path.

Tier two

Controls that may be implemented in a project

These are the practices we design toward. Which ones apply is decided per engagement with your security, data, and risk owners. Listing a control here is not a statement that it is active in your environment or that we have verified it there.

Access

  • We work within the access your organisation grants, using your identity provider where one exists
  • Least-privilege service accounts scoped to the specific objects a workflow needs
  • Read-only access by default; write access is requested explicitly and separately
  • Access is reviewed at go-live and on a schedule you set afterwards

Data

  • Only the data a workflow needs is used, and sensitive categories are excluded wherever the workflow allows
  • Retrieval mirrors your existing permissions so nobody sees content they could not open directly
  • Retention windows are agreed before build rather than inherited from a default
  • Assessment submissions are for scoping only — do not send confidential, regulated, or personal data

Integrations and change

  • Integration points, credentials, and data flows are documented before build
  • Changes go through your existing change process, not around it
  • Environments are separated, and testing uses representative rather than live sensitive data where possible
  • Rollback and shutdown paths are defined before anything reaches production

Testing and monitoring

  • An evaluation set built from your real cases, agreed before launch
  • Logging of inputs, retrieved sources, and outputs to the extent your policy permits
  • Sampling and drift review after launch, with named owners
  • Cost, quality, and exception rates reported on a regular cadence

Tier three

Controls verified in NeuronFlow's own environment

This short list is limited to what we operate ourselves on this website and can confirm by inspection. It is a self-assessment, not an audit, and it says nothing about controls in a client environment.

This website and the assessment form

  • Assessment answers are ranges and categories only — the form does not request names of records, customers, or case detail
  • Submissions are validated server-side against a fixed schema with a payload size limit before anything is accepted
  • Answers are never placed in the URL, and analytics events carry no free text, contact detail, or system names
  • Submission endpoints are rate limited and protected against automated posting
  • Credentials for lead delivery are held in environment variables, never in client code or logs
  • Application logs record outcome and error type, not the content of a submission

What this tier does not include

  • No third-party audit, penetration test report, or certification of this website
  • No claim about the security posture of any client system we have worked in
  • No trust badges or partner logos — we display none without documented authorisation

Shared responsibilities

NeuronFlow

  • Design workflows around your controls and document data flows
  • Build with least privilege and defined human checkpoints
  • Test against agreed evaluation criteria and report results honestly
  • Hand over documentation, owners, and monitoring practice

Your organisation

  • Own the underlying platform, identity, and infrastructure security
  • Approve which data may be used and set retention and access policy
  • Provide the named reviewers and owners the design depends on
  • Run legal, regulatory, and risk review appropriate to your sector
Security lifecycle of an AI workflow

Security is decided at each stage, not reviewed once at the end. Each stage has an owner and a record.

  1. 01Scope

    Decide what data is in play

    Data categories, sensitivity, and residency are agreed before any system is connected.

  2. 02Design

    Set access and retention

    Permissions, retrieval scope, retention periods, and logging are designed into the workflow.

  3. 03Build

    Connect through least privilege

    Service accounts get only the access the workflow needs, with credentials held in managed secrets.

  4. 04Test

    Evaluate before release

    Access boundaries, failure behaviour, and output quality are tested against defined cases.

  5. 05Release

    Approve with named owners

    A business owner and a technical owner sign off the scope that goes live.

  6. 06Operate

    Monitor and review

    Access reviews, log review, exception rates, and incident routes run on a schedule.

  7. 07Retire

    Remove access and data

    Connections, indexed content, and credentials are removed when the workflow ends.

What we do not claim

Boundaries

  • No SOC 2, ISO 27001, HIPAA, PCI, or GDPR certification or compliance guarantee
  • No claim that any AI system is free of error, bias, or misuse
  • No independent verification of the practices described on this page
  • No responsibility for the security of platforms, models, or vendors you contract directly

Request a security conversation

Security review happens inside a scoped engagement, where we can look at your actual systems, policies, and constraints. If you have a security question about a proposed implementation — or believe you have found a vulnerability in something we operate — contact us and describe the issue without including sensitive data or exploit details in the first message. We will respond with a secure channel for the detail.

What to expect from AI: AI outputs can be incomplete or wrong. NeuronFlow designs appropriate review, access, testing, monitoring, and escalation into each solution. Capabilities and controls depend on the use case, data, systems, and approved scope.

Find the AI opportunities worth implementing in your business.

Start with a structured assessment of your workflows, systems, and data, and leave with a prioritized view of where AI can create real value.