How Teams Solve It Today

There are four patterns teams usually reach for when giving agents API access. Each solves the immediate problem quickly, but each leaves security or operability gaps.

Hardcoded API keys

The simplest pattern: read one token from an environment variable and use it for every request.

import { Octokit } from "@octokit/rest";

const octokit = new Octokit({
  auth: process.env.GITHUB_TOKEN,
});

// Every agent instance, every user, every task: same token
const repos = await octokit.repos.listForAuthenticatedUser();

A common MCP server pattern looks like this:

# mcp_server.py
import os
from github import Github

GITHUB_TOKEN = os.environ["GITHUB_TOKEN"]  # read once at startup

@server.tool("list_issues")
async def list_issues(repo: str) -> str:
    gh = Github(GITHUB_TOKEN)               # same token for every caller
    issues = gh.get_repo(repo).get_issues(state="open")
    return "\n".join([f"#{i.number}: {i.title}" for i in issues])

@server.tool("create_issue")
async def create_issue(repo: str, title: str, body: str) -> str:
    gh = Github(GITHUB_TOKEN)               # same token, now used for write
    issue = gh.get_repo(repo).create_issue(title=title, body=body)
    return f"Created issue #{issue.number}"

It works for demos. In production, every caller gets the same long-lived power.

Shared service account

A step up from a raw key: create one bot account per platform and share it across agents, scripts, and pipelines.

# config.yaml shared across multiple services
github:
  token: ghp_xxxxxxxxxxxxxxxxxxxx  # github-bot
slack:
  token: xoxb-xxxxxxxxxxxx         # eng-bot
linear:
  api_key: lin_xxxxxxxxxxxx        # automation account

const config = readConfig("config.yaml");
const octokit = new Octokit({ auth: config.github.token });

await octokit.pulls.create({
  owner: "acme-corp",
  repo: "backend",
  title: "Fix: update dependency",
  head: "fix/dep-update",
  base: "main",
});

Audit logs show one actor (github-bot) for many systems. Attribution becomes guesswork.

User token passthrough

Here, the agent receives the user’s OAuth token directly.

async function handleAgentRequest(userSession: UserSession) {
  const agent = new Agent({
    githubToken: userSession.accessToken,
    slackToken: userSession.slackAccessToken,
  });

  await agent.run(userSession.prompt);
}

This feels natural but usually overgrants permissions.

What task needs:                  What token grants:
- Read PRs in acme/backend        - Read PRs in acme/backend
                                  - Read/write across other repos
                                  - Admin capabilities the user has
                                  - Broader org/workspace access

The agent inherits the user’s full authority, not the task’s minimum authority.

Long-lived personal access tokens

Common in CLI agents and unattended automations: users paste PATs/API keys into .env.

# .env
GITHUB_PAT=ghp_xxxxxxxxxxxxxxxxxxxx
LINEAR_API_KEY=lin_api_xxxxxxxxxxxx
SLACK_TOKEN=xoxb-xxxxxxxxxxxx

import os
from dotenv import load_dotenv

load_dotenv()

class AgentTools:
    def __init__(self):
        self.github_token = os.environ["GITHUB_PAT"]
        self.linear_key = os.environ["LINEAR_API_KEY"]
        self.slack_token = os.environ["SLACK_TOKEN"]

    async def create_pr(self, repo, title, branch):
        headers = {"Authorization": f"Bearer {self.github_token}"}
        async with httpx.AsyncClient() as client:
            resp = await client.post(
                f"https://api.github.com/repos/{repo}/pulls",
                headers=headers,
                json={"title": title, "head": branch, "base": "main"},
            )
        return resp.json()

Over time, the same token spreads widely:

grep -r "ghp_" ~/.config/ ~/projects/ ~/.env*

These tokens are broad, long-lived, and hard to rotate without outages.

These patterns ship quickly. They fail when agents move into production and teams need least privilege, attribution, and controlled revocation.

​Hardcoded API keys

​Shared service account

​User token passthrough

​Long-lived personal access tokens

Hardcoded API keys

Shared service account

User token passthrough

Long-lived personal access tokens