Let an agent act for a person, not instead of one.

• 01

  The key never expires

  An agent ships with a static credential in an environment variable. It works on the first day and on the thousandth. Rotating it means finding every place it was copied to, and nobody knows how many places that is.

  ONBE_API_KEY=sk_live_…

• 02

  It can do more than the person who asked

  The agent holds the key’s authority, not the caller’s. Someone with read access asks it to summarise a ticket, and the agent could have closed the project — because the key could, and nothing narrowed it to the person.

  user: read · agent key: read, write, admin

• 03

  The log says the agent did it

  When the audit is read back, every line names the service account. Which human was behind any given action is a question answered by guesswork, timestamps and chat history, if it is answered at all.

  actor=svc-automation sub=?

const client = new OnbeClient({
  issuer: required('ONBE_ISSUER'),
  agentId: required('ONBE_AGENT_ID'),
  kid: required('ONBE_AGENT_KID'),
  privateKey: readFileSync(required('ONBE_AGENT_KEY_FILE'), 'utf8'),
  // … onRefresh and onRefreshError
});

const session = await client.exchange({
  subjectToken: required('ONBE_SUBJECT_TOKEN'),
  resource: required('ONBE_RESOURCE'),
  scope: required('ONBE_SCOPE'),
});

// … then, for as long as the task has left to run:
while (Date.now() < end) {
  const response = await fetch(toolUrl, {
    headers: { authorization: `Bearer ${await session.accessToken()}` },
  });
  // … count the answer, wait, go round again
}

const guard = new OnbeGuard({
  issuer: process.env['ONBE_ISSUER'] ?? 'http://127.0.0.1:5100',
  audience: 'https://jira.internal',
  tools: { search: { scope: 'jira:read' }, comment: { scope: 'jira:comment', highRisk: true } },
});
createServer((req, res) => serve(req, res).catch((e) => guard.reject(res, e))).listen(port());
async function serve(req: IncomingMessage, res: ServerResponse): Promise<void> {
  const auth = await guard.authenticate(req.headers.authorization);
  await (await jira()).handleRequest(Object.assign(req, { auth }), res);
}

Both files are typechecked in the SDK repository’s continuous integration, so neither is code that only ever existed in a screenshot. What is shown here is an excerpt of each, named down to the line so it can be held against the original.

• RFC 8693

  Token exchange

  The one endpoint. The user’s access token and the agent’s signed assertion go in as subject and actor; a task token scoped to the intersection comes out. When sub-agent delegation lands, the previous actor nests inside the new one exactly as §4.1 describes; v0.1 issues depth 1 only.

• RFC 7662

  Introspection

  A tool server asks whether a token is still good. Tools marked high-risk ask on every call, which is what makes a revocation take effect immediately instead of whenever the token would have expired.

• RFC 7009

  Revocation

  Kill one token by its jti, or revoke the task and every grant delegated beneath it. Descendants are written to the ledger with the parent as the reason, so the shape of what was stopped is recoverable afterwards.

• RFC 8707

  Resource indicators

  A token is minted for one audience and is not a token for another. The agent must already be registered for that audience, so a misconfigured client cannot ask its way into a system it was never meant to reach.