Service Account or Bot Delegate¶
Software or tool — instantiates Proxy Mediation
A non-human machine identity that carries narrowly-scoped credentials to act for a principal automatically, with every action attributable and its credentials rotated or revoked when stale.
A Service Account or Bot Delegate is a non-human identity — a machine credential — that performs actions on behalf of a human, team, or service without exposing the principal's own identity or full credential set. Its defining feature is that the delegate is an autonomous credential, not a person or a request stream: it holds its own narrowly-scoped permissions and acts automatically, so the entire safety story is least-privilege scoping, attributable logging, and disciplined credential lifecycle. Unlike a proxy that filters a population's traffic, a service account is the actor. That is exactly why it fails dangerously when its credentials are broad and stale: a machine identity nobody is watching, holding more power than it needs, is a standing key under the mat.
Example¶
A platform team runs continuous deployment. Instead of an engineer's personal credentials pushing releases to production — which would expose a human's full access and vanish when they leave — the pipeline acts as a Kubernetes service account. It is granted exactly the permissions it needs: deploy to the staging and production namespaces, read the image registry, and nothing else. When the pipeline ships a release, the action is performed by that machine identity and logged as such, so an auditor can see precisely which automated deploy touched what.
The design's real work is in the lifecycle. The account's token is short-lived and rotated automatically, so a leaked credential expires fast; access reviews flag it if its scope has crept beyond what it uses; and if anomalous behavior appears — a deploy at 3 a.m. to a namespace it never touches — the credential can be revoked immediately and the incident escalated. GitHub Actions' workflow identities and cloud service accounts are the everyday instances. What this delegate is not doing is presenting a human face or interpreting a principal's intent — it executes a tightly-bounded, pre-authorized function.
How it works¶
- Give the machine its own identity. A distinct non-human credential acts for the principal, so the human's identity and full credentials are never exposed in automation.
- Scope to least privilege. The account holds only the specific permissions its task requires, nothing broader.
- Attribute every action. Automated actions are logged under the account's identity, so machine activity is auditable and not blended into a human's trail.
- Manage the credential's life. Tokens are short-lived and rotated; scope is reviewed for creep; and anomalous or compromised credentials are revoked and escalated.
Tuning parameters¶
- Privilege breadth — minimal task-specific scope versus broad standing access. Broader scope is convenient and turns any leak into a much larger blast radius.
- Credential lifetime — short-lived, auto-rotated tokens versus long-lived static secrets. Short lifetimes shrink the window a stolen credential is useful; they need automation to refresh.
- Monitoring sensitivity — how aggressively anomalous account behavior triggers alerts or auto-revocation. Sensitive monitoring catches compromise early and risks halting legitimate automation on a false positive.
- Attribution granularity — logging at the account level versus tying each action to the triggering human or workflow. Finer attribution aids forensics and adds logging overhead.
When it helps, and when it misleads¶
A service account helps wherever automation must act repeatedly for a principal without a human in the loop — CI/CD, scheduled jobs, service-to-service calls — and where blending that activity into a person's credentials would be unsafe and unauditable. It gives machine work its own bounded, attributable identity.
Its signature failure mode is the stale, over-broad credential: an account created for one task, quietly granted more access over time, never rotated, and watched by no one — the classic path to a breach that pivots through a forgotten bot. Least-privilege scoping is the animating safeguard, but privilege creep and secret sprawl erode it silently.[1] The guarding discipline is to grant the minimum scope, prefer short-lived rotated credentials over long-lived secrets, review accounts for creep and disuse, and keep a fast revocation-and-escalation path for the moment one misbehaves.
How it implements the components¶
authority_scope— least-privilege permissions fix exactly which actions the machine identity may perform for the principal.accountability_record— actions logged under the account's own identity make automated activity attributable and auditable.proxy_health_signal— token expiry, access reviews, and anomaly monitoring signal when a credential has gone stale, over-broad, or compromised.revocation_and_escalation_path— credentials can be rotated or revoked and incidents escalated the moment the delegate misbehaves.
A service account does not front a whole population of clients' outbound requests or decide where those clients may go — principal_or_protected_party in that population sense, delegation_rule over a request stream — that traffic-mediating role belongs to Forward Proxy Server; a service account is a single acting identity, not a gateway for others.
Related¶
- Instantiates: Proxy Mediation — the machine-identity form of the archetype, governed by least privilege and credential lifecycle.
- Consumes: Power of Attorney or Mandate Document — its grant of scope is the machine-readable analog of a mandate that authorizes what it may do.
- Sibling mechanisms: Forward Proxy Server · Reverse Proxy Server · Privacy Relay or Anonymizing Proxy · Cached Representation Service · Broker Intermediary · Escrow Service · Human Agent or Representative · Guardian or Delegate Role
Editorial Notes¶
Form Classification¶
Form family: Organization, Role & Governance
Rationale: Service Account Or Bot Delegate operates by maintains a distinct non-human actor with scoped authority, credentials, accountability, and revocation. That concrete deployed or enacted form is Organization, Role & Governance under the frozen taxonomy.
Nearest alternative: Structure, Architecture & Configuration — Although Structure, Architecture & Configuration can support this mechanism, the frozen evidence makes its operative form the act that maintains a distinct non-human actor with scoped authority, credentials, accountability, and revocation; the alternative is therefore secondary rather than defining.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: A non-human principal with scoped, rotatable credentials is an identity-and-access-management pattern for automated systems.
Related originating lineages:
- Engineering & Design — Engineering design, reliability, and systems-safety practice supplies a parallel or contributing lineage for the mechanism's defining operation: a non-human machine identity that carries narrowly-scoped credentials to act for a principal automatically, with every action attributable and its credentials rotated or revoked….
- Law & Governance — Agency doctrine clarifies delegated authority and accountability for acts taken on another's behalf.
- Organizational & Management Science — Role design defines ownership, review, and lifecycle responsibility for machine delegates.
- Security Studies & Intelligence Analysis — Least privilege, credential rotation, revocation, and attributable logs are core security controls.
Review resolution: The blind reviewers agree that computer_science is the primary origin and differ only on alternate origin disagreement, origin mode disagreement, encyclopedia synthesis disagreement. I preserve every independently explained alternate from both records rather than imposing a numeric cap. I retain cross_disciplinary_synthesis because the combined record shows material contributions from several lineages. The broader reach of specialized records portability separately from historical provenance, and encyclopedia_synthesis=true preserves the affirmative synthesis judgment where either reviewer identified one.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] The principle of least privilege (Saltzer & Schroeder, 1975) holds that every actor should operate with the minimum authority its task requires, so that any compromise or error can do as little damage as possible. Service accounts are where the principle is most often violated in practice — through privilege creep and unrotated secrets — which is why their design is dominated by scoping and lifecycle rather than by interface or negotiation. withdrawn registry ↩