Skip to content

Credential Delegation Architecture for Agents

1Password Credential Broker converges with the upstream Drupal authority model.

This architecture defines how autonomous agents authenticate across the Bluefly platform. Agents must operate under governed machine identities without borrowing human credentials, inspecting secret values, or managing ad-hoc token pools.

1. Architectural Principles

  1. No Human Borrowing: Agents NEVER borrow Thomas's (or any other human's) identity.
  2. No Value Inspection: Agents NEVER inspect, print, or read raw secret values.
  3. No Ad-Hoc Tokens: Agents NEVER generate random PATs or temporary local tokens to bypass identity rules.
  4. No Item Enumeration: Agents NEVER enumerate 1Password items looking for credentials.
  5. Delegated References: 1Password authenticates and delivers secrets via semantic references (op://Vault/Item/field) only.

2. Core Components

The architecture relies on the composition of the following canonical components:

  • 1Password (System of Record): The sole authority for storing and resolving secrets.
  • 1Password Service Accounts (or Connect): Provides the machine identity for agents, allowing programmatic access to specific 1Password vaults without human interaction.
  • Gas City Agent Identity: Defined in agent.toml (or equivalent configuration), specifying the agent's role and bounding its permissions.
  • Semantic References: Secrets are passed to runtime environments via op:// references.
  • Drupal Native Auth: Target Drupal rigs authorize actions using Drupal's native capability and permission models, not custom SAML/LDAP wrappers.

3. Credential Flow

The secure path for agent authentication is designed as a delegation chain:

  1. Agent Needs Credential: An agent executing a Formula or task requires authentication to a target platform (e.g., GitLab, Drupal).
  2. Gas City Resolves Identity: Gas City reads the agent's configuration (agent.toml) and determines its machine identity and required scopes.
  3. 1Password Delivery: Using the agent's mapped 1Password Service Account, the system resolves the necessary op:// references into the runtime environment (e.g., injected environment variables or configuration files) without exposing the values to the agent's LLM context.
  4. Target Authentication: The target platform (Drupal, GitLab) receives the secret directly from the runtime, authenticates the agent, and authorizes actions based on its native permission model.

4. Current State vs. Target Architecture

Capability What Exists Today What is Needed (Target State)
Identity Source Human fallbacks (Thomas's identity) often used when machine identities gap. Fully provisioned 1Password Service Accounts for each governed agent.
Secret Delivery Wrapped op run calls around individual shell commands. Native runtime injection of op:// references at the Gas City worker/environment level.
Drupal Auth Additive role-based permissions, occasionally bypassing standard agent service accounts. Strict mapping of Gas City agent identities to dedicated Drupal service accounts with bounded native roles.
Token Lifecycle Static tokens manually rotated or managed. Short-lived, dynamically retrieved credentials where possible, heavily relying on 1Password Service Accounts.