docs(enterprise): add service accounts page

docs/docs.json

@@ -158,6 +158,7 @@
                     "pages": [
                       "enterprise/identity-and-access",
                       "enterprise/identity-sso-and-scim",
+                      "enterprise/service-accounts",
                       "enterprise/hierarchical-settings-and-org-control"
                     ]
                   },

docs/enterprise/service-accounts.mdx

@@ -0,0 +1,78 @@
+---
+title: Service Accounts
+description: Non-human identities for running Factory automation in CI/CD pipelines, scripts, and Droid Computers.
+---
+
+Service accounts are non-human identities that automate work on behalf of your organization. Use them when a workload should belong to your organization instead of a specific teammate, such as CI/CD pipelines, scripts, Slack automations, or Droid Computers.
+
+<Info>
+  **Enterprise Feature** — Service accounts are available to enterprise customers. [Contact us](mailto:sales@factory.ai) to learn more.
+</Info>
+
+---
+
+## Start with the basics
+
+<CardGroup cols={2}>
+  <Card title="Create a service account" icon="user-plus">
+    Add a stable identity from Settings. Give it a clear name and optional description so teammates know what it runs.
+  </Card>
+  <Card title="Generate API keys" icon="key">
+    Create keys for scripts, CI jobs, and other automated workloads. Key values are shown only once, so copy them and store them securely.
+  </Card>
+  <Card title="Attach Droid Computers" icon="server">
+    Create computers owned by the service account so long-running work can continue under the same identity.
+  </Card>
+  <Card title="Configure Git access" icon="code-branch">
+    Use your organization's GitHub App installation for GitHub. For GitLab Cloud, add a service-account GitLab token in Settings.
+  </Card>
+</CardGroup>
+
+---
+
+## How service accounts work
+
+A service account authenticates with a Factory API key and runs as its own principal. Sessions, computers, billing events, and audit surfaces are attributed to the service account instead of a human user.
+
+Service accounts must be active to authenticate. If you mark one inactive or delete it, new requests using its keys fail, and workloads depending on that identity should be moved or restarted with another account.
+
+---
+
+## Manage access safely
+
+<AccordionGroup>
+  <Accordion title="Use short-lived keys when possible">
+    Set expiration dates for keys that are used in temporary automation. Short-lived keys limit the blast radius if a key is accidentally exposed.
+  </Accordion>
+
+  <Accordion title="Rotate keys regularly">
+    Create a new key, update the workload, then revoke the old key. Regular rotation reduces the risk of compromised credentials.
+  </Accordion>
+
+  <Accordion title="Keep names stable">
+    Service account names are immutable identifiers. Create a new service account if you need a different name.
+  </Accordion>
+
+  <Accordion title="Delete when finished">
+    Deleting a service account revokes its access and cleans up owned Factory resources where possible.
+  </Accordion>
+</AccordionGroup>
+
+---
+
+## Common use cases
+
+<CardGroup cols={2}>
+  <Card title="CI/CD" icon="gear">
+    Run release, testing, or deployment workflows without depending on one engineer's account.
+  </Card>
+  <Card title="Slack automation" icon="message">
+    Configure channels or workflows to run Droid as a shared team identity.
+  </Card>
+  <Card title="Repository automation" icon="code">
+    Clone, push, and operate on repositories with credentials managed for the service account.
+  </Card>
+  <Card title="Persistent computers" icon="desktop">
+    Keep Droid Computers tied to an automation identity instead of a teammate's personal account.
+  </Card>
+</CardGroup>