When a coding agent investigates a production bug, it might need to read a repository, query logs, and open a pull request. If it finds something suspicious in another service, reading that service’s logs could be a reasonable next step. Whether it should have access depends on the investigation, but its credentials often grant the same permissions regardless of the task.
API keys and tokens usually say little about what the agent was asked to do, who assigned it, or how the task reached the agent. Intent-based authorization uses that purpose and context to determine access for each task. It evaluates the requested access against the permissions of the person or system that assigned the task, the agent’s assigned purpose, and organizational policy. A request to retrieve HR records, for example, should remain outside a customer-support agent’s remit even if its tools could reach them.
Access follows the task
Consider an alert reporting errors in a payments service. An orchestrator proposes an investigation, and an authorization service evaluates it using the authenticated trigger, the agent’s permitted role, and policy established outside its control. It then grants an incident agent read access to that service’s logs for the previous hour.
As the investigation progresses, the agent finds evidence pointing to an authentication service and requests those logs too. Policy may permit that additional access automatically or require human approval, but the runtime blocks the request until access is granted. The agent can follow a new lead without deciding for itself which permissions come with it.
If the incident agent delegates log analysis, the receiving agent uses its own verifiable identity and gets only the access needed for its part of the task, within its own permissions. That handoff can narrow the existing grant but cannot expand it, and it preserves the task context and records who passed it along.
Throughout the investigation, authorization must distinguish trusted context from untrusted content. An authenticated alert can contain a log line written by an attacker, so trusting the alert’s source does not mean instructions inside it can authorize access to another system.
Running a software factory
In a software factory, agents increasingly propose tasks as well as execute them. An orchestrator can watch incidents and scanner findings, pick up bugs without a ticket, and dispatch agents to investigate and propose fixes. Its ability to identify useful tasks doesn’t give it permission to assign whatever access those tasks might require. The factory needs an independent authorization decision, with limits enforced as the agents run.
Those limits extend beyond access because an agent can pursue a legitimate task badly. It might make thousands of unnecessary requests or produce a change that passes review but fails in production. Budgets help limit consumption, while checks and tests help determine which changes can advance. Audit records outside the agent’s control preserve what happened, and revocable access gives operators a way to stop activity when something goes wrong.
The Software Factory reference architecture, developed by Keycard, Docker, Barclays, Socket, and Aaron Stanley, shows how these controls fit together. Built on Agent Baseline, it defines four boundaries: identity and access, supply chain, sandbox, and network. These boundaries hold as autonomy increases, combining task-scoped access with controls on the software agents use, where they execute, and which systems they can reach.
A factory can let agents decide what to investigate next while keeping decisions about access under independent control. That separation allows it to take on more responsibility and autonomy without giving every agent broader standing permissions.