Security & permissions
Not just where your data lives. Who an agent acts for.
Our agents work inside the systems you already run. The real question is not only how we store data, but what an agent is allowed to do, and on whose authority. This page covers how the platform is built, what you control, and what we do not claim.
Last updated: August 11th, 2026
01 · Our security principles
Six rules the platform is built around.
Agents inherit your permissions. They do not create new ones.
An agent acts through your existing systems using access you authorise. It cannot see or do anything a properly permissioned user in that system could not.
We do not copy your business into our database.
Data is read from and written to your source systems. We are not a second store of record you now have to secure.
Least privilege, by default.
Access, for agents, for your team and for ours, is limited to what the task requires.
Everything an agent does is logged.
At workflow level and at node level. Nothing an agent does is invisible.
You can stop it.
Any agent can be paused, modified or switched off at any time, by you.
We claim only what we operate.
Section 12 sets out what this page does not claim. We would rather tell you than let you assume.
02 · Where your data sits
Three categories, handled differently.
Your source systems
Your CRM, HR system, accounting platform, file storage and the rest remain the record. Agents read from and write to them through the connections you authorise. Actions taken by an agent are recorded in that system as they would be for any other user.
Your Company Brain
Documents, manuals, policies and configuration files you upload to Growy, stored to power your Assistants and Agents. Encrypted at rest, logically separated from every other client, and deletable by you at any time.
Workflow and audit data
The record of what your agents did: runs, steps, inputs, outputs, approvals and escalations. Retained per the periods in our Privacy Policy and accessible to permitted users in your organisation.
03 · Permissions
The part most AI platforms handle badly.
So we are specific about it.
- Connections are authorised by you. Each integration is connected by an administrator in your organisation, at the permission level you choose. Where a system supports scoped access, you grant only the scopes the workflow needs.
- Agents operate within those permissions. An agent connected to your HR system with read access to leave records cannot read payroll. The boundary is enforced by the source system, not by our promise.
- Access can be revoked by you, from the source system, without our involvement. Revoking a connection stops the agent's access immediately.
- Within Growy, access is role-based. Your administrators control who can build workflows, who can run them, who can approve steps, and who can see logs and outputs.
- Approval steps are permissions too. Where a workflow includes a human approval, only designated people can give it. Approvals are recorded with who gave them and when.
04 · Encryption
In transit and at rest.
- Data is encrypted in transit using TLS.
- Data is encrypted at rest in our infrastructure.
- Data sent to model providers for processing is encrypted in transit.
05 · Separation between clients
Logically separated, always.
Each client's Company Brain, integrations, workflows and logs are logically separated. Agents operate only within the account they belong to and cannot reach data, knowledge or connections belonging to another client.
Your data is never used to train models, is not shared with other customers, and does not inform another client's agents.
06 · Growy's own access to your data
Our personnel do not browse client data as a matter of course.
Access is granted on a least-privilege basis and limited to what is required to deliver, support or troubleshoot your deployment, for example, when your team raises a support request, or during build and testing that you have commissioned. Internal access is controlled by role.
If you require additional restrictions on our access, raise it during scoping and we will address it in your agreement.
07 · Audit logging
Every agent run is recorded at two levels.
Workflow level
What triggered the run, when, the path it took, and how it ended.
Node level
Each step: inputs, outputs, the system touched, whether a threshold or approval was involved, and where the run stopped if it stopped.
This exists so that agent behaviour can be reconstructed end to end: to debug a failure, investigate an unexpected output, demonstrate to an auditor what happened, or improve the workflow. Log access is controlled by role, and extracts for your own workflows are available on request.
08 · Building and releasing safely
No agent goes live on our judgement alone.
Isolated testing.
Agents are built and tested in an isolated environment against real data before they touch live systems.
Client sign-off.
No agent goes live on our judgement alone. You review the tested behaviour and approve deployment.
Bounded autonomy.
Every agent is deployed at an agreed level of independence, with approval steps where you place them and confidence thresholds that escalate rather than guess. This is set out in full on our AI Governance page.
Reversibility.
Actions that are irreversible, externally binding, financially material, or that determine an outcome for an individual sit behind human approval.
09 · Infrastructure and subprocessors
Established providers, held to our terms.
We build on established cloud infrastructure providers, and we use a limited set of subprocessors for model inference, integrations and operational tooling.
Each subprocessor is bound by a written contract imposing data protection obligations no less protective than our own, is assessed before engagement, and is reviewed thereafter. The current named list forms part of our Data Processing Agreement and is available at [email protected].
Categories, transfers and safeguards
Full detail is on our GDPR & EU AI Act page.
10 · Monitoring, vulnerabilities and incidents
Watched, patched, and reported on when it matters.
We monitor our platform for unusual activity, apply security updates to our infrastructure and dependencies, and review our security posture as the platform changes.
If we become aware of a security incident affecting your data, we notify you without undue delay, with the information you need to meet your own obligations. Where we are the controller, we notify the relevant supervisory authority within 72 hours where the incident is likely to result in a risk to individuals' rights and freedoms.
If you believe you have found a vulnerability in Growy, report it to [email protected]. We will acknowledge it and work with you on resolution. We ask that you do not publicly disclose it before we have had a reasonable opportunity to respond.
11 · What you control
This is not a small list.
- Which systems are connected, and at what permission level
- Which documents and knowledge enter your Company Brain
- Who in your organisation can build, run, approve or view
- Where human approval is required in each workflow
- The autonomy level at which each agent operates
- Pausing, modifying or switching off any agent, at any time
- Exporting or deleting your content
Because agents inherit your permissions, keeping access in your source systems accurate is part of keeping your Growy deployment secure. When someone leaves your organisation or changes role, updating them in the source system updates what the agents can do on their behalf.
12 · What we do not claim
Security pages tend to imply more than they say. Ours does not.
- We describe the controls we operate. We do not present our infrastructure providers' compliance posture as our own.
- We do not guarantee uninterrupted or error-free service. Our commitments on availability, where they exist, are set out in your agreement rather than on this page.
- No system is completely secure. We apply the controls described here and we are honest that risk cannot be eliminated.
If your procurement process has specific requirements, tell us early. We would rather have that conversation at the start than at signature.
13 · Security questionnaires and reviews
We are used to enterprise security review.
On request we provide:
- a security overview
- our Data Processing Agreement and subprocessor list
- information to support your DPIA
- architecture and data flow detail for your deployment
- completed responses to your own security questionnaire
Request any of these at [email protected].
15 · Contact
Questions about how this works? Ask directly.
We may update this page as the platform and our practices change. The current version is always shown by the date at the top.