# Security, privacy and control

> Security requirements belong in the workflow scope. We agree the data needed, who may access it, where it is processed and which actions require review before connecting business systems.

**Make the data path explicit**

_Example design to agree_

1. **Permitted sources** — Define the records and access needed for this task. Owner and permissions
2. **Agreed processing** — Name providers, destinations and what each step retains. Storage and retention
3. **Review and action** — Test who can review, authorise and stop the workflow. Approval and recovery

Document each connection, including model calls, logs and notifications.

Controls and hosting arrangements are confirmed for the implementation.

## Agree where data is stored and processed

A deployment decision covers more than the application server. Source records, uploaded files, search indexes, model requests, logs and backups may each have a different destination. We assess the proposed data flow against your requirements and document the selected services and responsibilities. A cloud, private network or on-site requirement needs a feasibility review; this page is not a guarantee that every configuration is available.

**Questions to settle before connecting data**

| Area | Required decision |
| --- | --- |
| Application and storage | Where the workflow runs, who owns the accounts and which regions are used. |
| Models and external services | Which providers process each input and under which account settings and terms. |
| Indexes and logs | What is copied or retained, who can access it and when it is removed. |
| Support and recovery | Who may troubleshoot, how access is granted and how the workflow can be stopped. |

## What leaves your environment

Review each outbound path, including model calls, integrations, file processing, monitoring and notifications. A model request may include the prompt and retrieved business context. A notification may expose part of an output. Keeping an application inside a private network does not by itself keep all processing there.

### Keep unnecessary data out of the workflow

Start with the smallest set of records needed for the task. A reporting pilot may need totals and operational identifiers rather than full customer profiles. An invoice reminder may need an account contact and payment status but no unrelated mailbox history. Redaction and filtering need checks of their own, including what appears in error messages and logs.

## Confirm provider retention and training settings

Data handling depends on the selected service, account configuration and agreement. Before use, confirm whether prompts and outputs are retained, whether they may be used for model training, which exceptions apply and how deletion works. Do not assume a consumer account and a business API have identical terms. Requirements that a provider cannot meet should change the design or stop that use.

## Access follows the permissions you grant

Use credentials scoped to the sources and actions the workflow needs. Access to a source and access to an output are separate questions: a service account may read material that not every reviewer should see. Client, department and property boundaries must therefore be checked in retrieval, storage and the interface, rather than relying on a prompt to keep them apart.

Agree how credentials are stored and rotated, who can grant access and what happens when permission is revoked. Tests should cover an unauthorised user, a removed permission and an attempt to retrieve another client's material. Source documents and messages are task data; embedded instructions must not grant the workflow new authority.

## Define and test approval controls

Begin with a draft-only workflow where that is sufficient. For a workflow that sends messages or changes records, define the exact action, allowed recipients or destinations, authorised approver and any limits. The application should enforce those checks. A statement in a prompt that asks the model to seek permission is not an access control.

- Show the proposed action and the output version the reviewer is approving.
- Recheck permission and relevant record state before execution.
- Handle rejection, expiry, retries and duplicate requests without unintended actions.
- Record the result and provide a clear way to pause the workflow.

The [action-risk guide](https://genaima.ai/insights/risk-classify-ai-agent-actions) offers an example policy to adapt to your organisation. The controls required for a particular workflow are agreed and verified in that implementation.

## Agree the run record and monitoring

Decide which records support troubleshooting and review: source references, output versions, approvals, attempted actions, failures and available usage information. Those records may themselves contain sensitive data, so access and retention matter. We scope the reporting needed for the project; a universal live audit console is not assumed.

## Evidence and procurement requirements

Use the [vendor questions checklist](https://genaima.ai/insights/questions-to-ask-ai-agent-vendors) to identify required evidence before implementation. This page makes no certification claim. If a certification, regional restriction or particular security control is a condition of the project, raise it early so that support and evidence can be confirmed in writing.

Genaima AI Ltd is registered in England and Wales, company number 17138081. The [privacy policy](https://genaima.ai/privacy-policy) describes this website's handling of personal information; project-specific data processing and operational responsibilities need their own agreement.

## Common questions on security and control

### Can we begin without sending business data to a model?

Yes, the initial discussion can use a description of the task or a redacted example. Decide what data is necessary and which processing arrangement is acceptable before an implementation uses it.

### Can everything stay inside our network?

That requirement needs a review of application hosting, models, integrations, logging and support access. We confirm feasibility before proposing a design that depends on it.

### Who can inspect a workflow's outputs?

The roles agreed for the implementation. Access should be tested for both permitted and denied users, including records belonging to different clients or departments.

- [Launch your autopilot](https://genaima.ai/contact) — Include any data-location, access or procurement requirements in your enquiry.

## Related

- [How a workflow runs](https://genaima.ai/how-it-works)
- [FAQ](https://genaima.ai/faq)
- [Risk-classifying AI agent actions](https://genaima.ai/insights/risk-classify-ai-agent-actions)
- [Questions to ask AI agent vendors](https://genaima.ai/insights/questions-to-ask-ai-agent-vendors)
- [Privacy Policy](https://genaima.ai/privacy-policy)

---

- Canonical page: https://genaima.ai/security
- More: [Home](https://genaima.ai/) · [About Genaima](https://genaima.ai/about) · [Contact Genaima](https://genaima.ai/contact) · [How a workflow runs](https://genaima.ai/how-it-works) · [The AI operating layer](https://genaima.ai/ai-operating-layer) · [Security & governance](https://genaima.ai/security) · [FAQ](https://genaima.ai/faq) · [Implementation partner](https://genaima.ai/partner) · [Solutions](https://genaima.ai/solutions) · [Industries](https://genaima.ai/industries) · [Compare](https://genaima.ai/compare) · [Insights](https://genaima.ai/insights) · [Glossary](https://genaima.ai/glossary) · [Tech stack & tools](https://genaima.ai/tech-stack) · [Resources](https://genaima.ai/resources) · [Pricing & scope](https://genaima.ai/pricing) · [Selected work](https://genaima.ai/work) · [llms.txt](https://genaima.ai/llms.txt)
- Contact: hello@genaima.ai