Security and governance

FastHook isolates automation resources by team. A signed-in user must be a member of the selected team, while a project API key authenticates only the team that owns that key. Use this boundary together with separate environments, narrowly scoped provider accounts, secret rotation, and an external approval process for production changes.

Current access model

| Principal | Access boundary | Important behavior | | --- | --- | --- | | Dashboard session | Teams listed in the user’s memberships | Selecting another team without membership returns 403 forbidden_team_access. | | Project API key | The team that owns the key | The key does not inherit a user identity or membership in another team. | | Global FastHook administrator | Deployment-wide administration | This is a platform operator capability, not an ordinary team role. Admin-only routes return 403 admin_required to other users. |

Membership records include a role such as owner or member. Ownership is used for team lifecycle safeguards: the last owner of a shared team must transfer ownership before deleting their account.

Current protected resource APIs authorize ordinary dashboard users at the team-membership boundary. Do not assume that an owner or member label provides fine-grained read, edit, reconnect, rotate, or replay permissions for each Workflow or resource. Any team member who can reach a protected endpoint must be treated as trusted for that team’s operational data and configuration.

Design team boundaries

• Use a separate team for production when test users must not access production payloads, credentials, or Actions.
• Use separate Sources, connected accounts, and project keys for test and production.
• Do not use a global administrator account for routine Workflow editing.
• Remove a user’s membership when they no longer need team access; changing a provider role alone does not remove FastHook access.
• Treat membership changes as security changes because protected resources include Workflows, Sources, Actions, Destinations, requests, events, attempts, connected accounts, and project secrets.

Provider permissions form a second boundary. Team access lets a user select a connected account, but the provider still decides which workspaces, repositories, channels, files, stores, and operations that identity can use. See Authentication and permissions.

Protect machine access

A project API key is a team-scoped bearer credential. Send it only over HTTPS in Authorization: Bearer ... or x-api-key, and send the intended team in x-team-id when using team-scoped Control API examples.

Recommended controls:

1. keep separate keys per environment;
2. store keys in the calling platform’s secret manager rather than source control;
3. never put a key in a query string, Workflow mapping, request fixture, screenshot, or support message;
4. rotate immediately after suspected exposure or when an automation owner changes; and
5. update every caller before retiring the old key, because rotation invalidates authentication with the previous value.

The project API key can access protected team resources, including the project-secret endpoint. It is not a limited “run this one Workflow” token. If a caller needs narrower authority, enforce that boundary in a separate service account, proxy, or deployment control rather than assuming per-Workflow scopes exist.

Separate operational duties

FastHook does not currently enforce a complete maker/checker workflow for graph edits. Establish the separation in your operating process:

| Duty | Suggested owner | Evidence to record | | --- | --- | --- | | Connect or reconnect a provider | Credential owner | Provider identity, approved scopes, accessible resources, test result | | Edit a Workflow | Automation maintainer | Change purpose, graph version before and after, test request or run ID | | Approve production activation | Service owner | Reviewed side effects, retry safety, rollback decision | | Rotate a secret | Security or service owner | Secret class, affected callers, rotation time, verification result | | Replay or repeat an Action | Incident operator | Original run/request ID, idempotency decision, resulting provider object ID |

Do not share credentials merely to separate these duties. Give each operator their own dashboard identity and keep approval evidence in the team’s change-management system.

Production change-control procedure

1. Describe the intended change, affected team, Source, Workflow, provider accounts, side effects, and rollback owner.
2. Confirm the selected team and environment before opening credentials or editing the graph.
3. Compare the current graph version and record it. Workflow saves use optimistic concurrency, so a stale update should be refreshed instead of force-applied.
4. Make the smallest graph or credential change needed.
5. Test with a recognizable canary event and verify Workflow Audit plus the provider-side result.
6. Have another operator review mappings, Paths, scopes, idempotency, and retry behavior when the change can create external side effects.
7. Activate gradually when the Source supports traffic narrowing.
8. Record the new version, run ID, outcome, and rollback decision.

FastHook stores immutable Workflow version snapshots for later Audit interpretation, but historical snapshots are not a one-click rollback mechanism. Restore a known-good graph as a new forward version. Follow Workflow versioning and migrations and the production-readiness checklist.

Offboarding checklist

When a maintainer, service account, or provider identity leaves:

1. transfer ownership if the user is the last owner of a shared team;
2. remove the FastHook membership;
3. rotate project API keys known to that principal;
4. reconnect or replace provider accounts owned by that identity;
5. rotate affected webhook, Source, Destination, or signing secrets;
6. inspect recent Workflow Audit, requests, and provider logs for unexpected use; and
7. run one controlled event through every affected production Workflow.

Continue with Secrets and credential rotation and Data handling and retention.