# AI acceptable use policy for employee-built internal apps

Status: DRAFT FOR ORGANIZATION REVIEW
Policy owner: [Name and role]
Organization: [Organization]
Approved by: [Authorized approver]
Effective date: [Date]
Review date: [Date]
Incident contact: [Contact]

## Purpose and scope

Employees may build internal apps with [approved AI tools] for [permitted tasks].
This policy covers source, deployment, company-data access, sharing and maintenance.
The organization approves this template before it takes effect.

## 1. Approved tools and data

Use only [approved tools/plans] and [permitted data classifications].
Begin prototypes with fictional records. Do not put source credentials or restricted
records into prompts without the organization's explicit authorization.
SpringRoll's Company Blueprint publishes guidance; it does not enforce tool choices
on every employee device. [Security owner] maintains the approved list.

## 2. Ownership and source

Record an App Owner, department, support contact and maintained source location in
the app handoff. SpringRoll records app ownership and immutable releases.
[Team manager] reviews these fields when a builder changes role or leaves.

## 3. Company-data access

Request only fields/query rules or native API methods/paths needed for the task.
SpringRoll Connect grants belong to an application environment. A separate authorized
reviewer must decide the request; an employee's own source access is not an app grant.
Source credentials stay server-side. Native endpoint grants do not filter every
field in the response; [data owner] reviews source-account permissions and returned data.
Set [expiry/review interval]. Verify allowed, denied and revoked requests.

## 4. Release review

For [defined risk classes], configure Staged release approvals before deployment.
SpringRoll defaults to Direct to Production; this policy does not change that setting.
Keep the release ID, reviewer, decision and acceptance evidence.
An agent may prepare and follow a deployment; it cannot record a required human approval.

## 5. User access

Choose the App Portal audience for each environment. Test an intended colleague and
a separate identity outside that audience. [App owner] must also protect and test the
direct provider URL, private APIs and server-side business permissions.
Portal audience controls alone are not proof that the direct app URL is protected.

## 6. Maintenance and incidents

Keep source, release history, test results and a current support contact.
Report unexpected access or an exposed credential to [incident contact].
Review and revoke the affected grant/connection or suspend the app where appropriate.
Revocation stops future access; it does not erase records already copied or exported.
[Incident owner] coordinates credential rotation and the response outside SpringRoll.

## 7. Exceptions and retirement

Document the exception, owner, reason, permitted scope, approver and expiry.
Do not treat a past approval as permission for a broader change.
Before retirement, identify affected users, preserve required records, revoke obsolete
grants and verify old provider URLs according to [retirement procedure].

## Acceptance record

- App, release and environment: [references]
- Owner and support contact: [names]
- Approved AI tool and data classification: [decision]
- Release workflow and reviewer: [decision]
- Allowed audience test: [expected / observed / date]
- Denied audience and direct-origin tests: [expected / observed / date]
- Data grant and revocation tests: [expected / observed / date]
- Open issues, exception owner and review date: [details]

Template reviewed 8 November 2026.
Control mapping: https://springroll.dev/blog/ai-acceptable-use-policy-template