handbook: allow scoped credentials for AI agents under review

[robmarcer]

Description

Rewrites point 5 of "Internal Use of AI by FlowFuse Team Members" in the AI Development and Customer Data Policy.

Point 5 currently bans giving any credential to an AI tool or agent outright. In practice there is legitimate work that needs an agent to hold a token, and a rule that is routinely inconvenient tends to get quietly ignored rather than followed. This replaces the blanket ban with a conditional that is stricter in the places that actually matter.

Under the new wording, a credential may be given to an AI tool or agent only when all of the following hold:

1. Discuss it first with at least one other team member before creating or sharing it.
2. Document the discussion by opening an Access / Permission Request issue in the admin repo, recording who was consulted, what the agent will do, the scope granted, and when the credential will be revoked.
3. Scope it to the job, for example a single FlowFuse team rather than the whole account.
4. Read only by default, with write access only where the task genuinely cannot be done without it.
5. Rotate and revoke, treating any credential an agent has held as spent, revoking it when the work is finished, and rotating anything that must persist per the Access Control Policy.

Two things stay prohibited outright, because neither can satisfy "minimum needed":

• Admin-scoped FlowFuse Cloud and Dedicated Instance PATs. This was the original concern behind point 5 and it is preserved, with the reasoning made explicit.
• Passwords and any other secret that cannot be scoped or revoked.

The net effect is a narrower blast radius than today. The current rule says no, which means the cases where someone does need it happen with no discussion, no record, and no scoping. This makes those cases visible and bounded.

Related Issue(s)

None. Follow-up to #5107, which introduced point 5.

Checklist

Most of the template checklist does not apply to a handbook policy change.

• I have read the contribution guidelines
• I have considered the performance impact of these changes (n/a, content only)
• Suitable unit/system level tests have been added and they pass (n/a)
• Documentation has been updated (this PR is the documentation)
• For blog PRs, an Art Request has been created (n/a, not a blog post)

Note for reviewers

@knolleary is the listed policy owner. @hardillb wrote the original point 5 and @allthedoll broadened it during review of #5107, so both have context on the intent being changed here.

The effective date in the header table has deliberately been left at 2026-02-18, matching how #5107 handled an amendment. Happy to bump it if the policy owner would prefer amendments to move that date.

[hardillb]

In practice there is legitimate work that needs an agent to hold a token, and a rule that is routinely inconvenient tends to get quietly ignored rather than followed

This is a problem, if this is the case then it needs to STOP now and be discussed.

As part of that discussion we need to understand what "there is legitimate work that needs an agent to hold a token" is and if it really does meet that criteria.

This can be discussed when Nick and Jam are back, but all work using tokens must stop until then, it is explicitly against stated policy.

[netlify]

✅ Deploy Preview for flowforge-website ready!

Name	Link
🔨 Latest commit	1827ae0
🔍 Latest deploy log	https://app.netlify.com/projects/flowforge-website/deploys/6a744acd13eedd0008723bd4
😎 Deploy Preview	https://deploy-preview-5520--flowforge-website.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
Lighthouse	1 paths audited Performance: 76 (🟢 up 12 from production) Accessibility: 96 (no change from production) Best Practices: 100 (no change from production) SEO: 92 (no change from production) PWA: - View the detailed breakdown and full score reports

---

To edit notification comments on pull requests, go to your Netlify project configuration.