AI rollout · Access policies
MixedIT & securityRolling out AI to 200 people with one access policy per team
Turning AI on for a whole company is mostly a question of who may do what. This architecture gives each team its own access policy, runs on your own provider keys and keeps personal data out of logs.
Valnora & Elric team5 min read
- ChatAsk questions and build in natural language.
- WorkflowsThe visual builder: blocks, models and integrations wired into agent logic.
- RelaysAI coworkers with a role, a schedule and approvals before external actions.
- LogsEvery run traced block by block.
- FilesOne store for documents your team and agents share.
An IT and security lead has been asked to give 200 people access to AI by the end of the quarter. Marketing wants image and video generation. Support wants drafted replies. Finance wants help with variance commentary but will not accept customer data sitting with a model provider. Engineering wants every model, today.
One setting for everyone fails at least one of those teams. This post lays out an architecture in Agent Serve where each team gets its own access policy, requests run on your own provider keys, personal data stays out of logs, and every change leaves a record.
The four layers
Four layers between 200 people and the models
People · Identity
- 01SSO sign-inStaff sign in through your identity provider; SCIM keeps the roster current.
- 02Permission group per teamMarketing, Sales, Support, Finance and Engineering each get their own group and policy.
Policy · What each team may use
- 03Allowed providersWhich model providers the team can reach in Chat, workflows and Relays.
- 04Denied tools and modelsSpecific tools or models switched off for the group.
- 05Media and costMedia Generation on or off, default media models and the cost confirmation threshold.
- 06Zero data retentionWith non-ZDR models switched off, only ZDR models run for the group.
Runtime · Keys and data
- 07Your provider keysSettings → Model API keys holds your keys, so usage runs on your agreements.
- 08PII redactionRedaction for logs, workflow input and block outputs; Guardrails masks data inside a workflow.
- 09Audit trailPolicy edits, key changes and Relay approvals recorded in the audit log.
Read the diagram top to bottom. Identity decides who someone is. The permission group decides which policy applies. The policy decides what they may use in Chat, workflows and Relays. The runtime decides which keys pay for it and what is kept afterwards.
Identity: sign-in decides the group
Connect your identity provider with SAML 2.0 or OIDC, and provision people with SCIM so joiners and leavers are handled where they already are. Create one permission group per team and assign people to it. In this example that is five groups for 200 people: Marketing 40, Sales 50, Support 60, Finance 25 and Engineering 25 (illustrative headcounts).
Keep the groups aligned with real teams, not with projects. A policy is easier to defend when it matches a line on the org chart.
Policy: what each team may use
What the solution produces
Five access policies for 200 staff (illustrative)
Checklist- Marketing (40): two providers allowed. Media Generation on, default image and video models set, cost confirmation at US$1.
- Sales (50): two providers allowed. Media Generation off. Integrations limited to the CRM, Gmail and Slack.
- Support (60): one provider allowed. Media Generation off. Browser agent tools denied. Guardrails required in reply workflows.
- Finance (25): Models Without Zero Data Retention switched off, so only ZDR models run and media generation is withheld.
- Engineering (25): all approved providers. Media Generation off. Cost confirmation at US$5 for test jobs.
Audit log entries from week one (illustrative)
Record- Mon 09:12
- Admin created permission group "Finance" and switched off non-ZDR models
- Mon 09:30
- Admin added the organisation’s provider key under Model API keys
- Wed 14:05
- Admin raised the Engineering cost confirmation threshold to US$5
- Thu 11:47
- Support lead approved a Relay’s drafted reply email
Each permission group carries an access policy, set in Settings → Access policies. The levers that matter for a rollout are:
- Allowed model providers and denied models. Narrow the catalogue to providers you have agreements with, and remove models you have decided against.
- Denied tools and allowed integrations. Support might not need a cloud browser agent. Sales might need only the CRM, Gmail and Slack.
- Media Generation switch and default media models. On for marketing, off for most other teams. Defaults stop people reaching for the most expensive video model by habit.
- Cost confirmation (USD). Generations estimated above the threshold, US$1 by default, ask before running. Raise it for teams that test heavier jobs.
- Models Without Zero Data Retention. Switch it off for finance and only ZDR models run. Media generation is withheld as a side effect, since media models have no ZDR endpoints.
Runtime: your keys, redacted logs
Add your provider keys in Settings → Model API keys. Requests then run on your agreements and rates. Without them, the platform key is used and usage is metered to the workspace, which is fine for a pilot.
Next, decide what is kept. Turn on PII redaction in Settings → Data retention for logs, workflow input and block outputs, and set a retention period your data protection lead agrees with. Inside workflows that handle customer text, such as support reply drafts, add a Guardrails block with PII detection to mask or block personal data before it reaches the model. For a closer look at what a provider does with data once it arrives, see what happens to your data when an AI model reads it.
The audit trail
Controls and governance
SSO and SCIM
Sign in through your identity provider with SAML 2.0 or OIDC, and provision people with SCIM.
Roles and permission groups
Admin, write and read roles per workspace, plus permission groups that limit which models, blocks and integrations a team can use.
Bring your own keys
Use your organisation’s own model provider keys at organisation or workspace level.
Zero data retention
Zero data retention with supported model providers, backed by your own provider keys and agreements or self-hosted models. Some provider features keep data by design, such as Gemini Deep Research, so they are outside zero data retention.
PII detection
A Guardrails block detects personal data and blocks or masks it before text reaches the next step.
Audit trail
Proposals, approvals, declines and executed actions are written to the workspace audit log, which admins can export.
Run logs
Every workflow run records each block’s inputs, outputs and errors, so a reviewer can trace how a result was reached.
Self-hosting
Run Agent Serve in your own cloud or data centre, next to the systems it reads.
More on how Agent Serve handles access, data and audit on the security page.
Policy edits, key changes and Relay proposals, approvals and declines are written to the workspace audit log, which admins can export. Run logs record each workflow block's inputs, outputs and errors, after redaction. Together they answer the two questions security reviews ask: who changed what, and what did the agent actually do.
A four-week rollout
- Week 1. SSO, groups and a strict default policy for everyone. Pilot with ten people per team on the platform key.
- Week 2. Add your provider keys. Loosen policies team by team based on what the pilots needed.
- Week 3. Turn on PII redaction and retention. Add Guardrails to customer-facing workflows.
- Week 4. Open to all 200. Review the audit log and denied requests weekly for the first month, then monthly.
The timings are a plan, not a promise. The order matters more than the dates: identity and policy first, then keys, then wider access. For the cost side of the same decisions, see keeping AI model costs low.
Questions teams ask
Do we have to bring our own keys?
No. Without your own keys, the platform key is used and usage is metered to the workspace. Many organisations start that way during a pilot and move to their own keys once they know which providers they will keep.
Why does switching off non-ZDR models stop media generation?
Image, video and audio models do not have zero data retention endpoints. When a group may only use ZDR models, media generation is withheld for that group as a result.
Can someone change their own team’s policy?
Access policies are set by admins. Members work within the policy of their permission group, and policy changes are written to the audit log.
What you need
- SSO configured with your identity provider, and SCIM if you want joiners and leavers handled automatically
- A list of teams with headcount and the AI jobs each one actually needs
- Provider agreements and API keys for the model providers you allow
- A decision per team on media generation, cost confirmation threshold and zero data retention
- PII redaction settings agreed with your data protection lead, and a retention period for logs
- A named owner who reviews policies monthly as the model catalogue changes