Coding agents investigating production bugs may need to read repositories, query logs and open pull requests. When a lead points to another service, access depends on the investigation, but credentials often grant the same permissions regardless of the task. API keys and tokens usually do not record what the agent was asked to do, who assigned the work or how it arrived. Intent-based authorization uses that purpose and context to assess each access request against the assigner’s permissions, the agent’s role and organizational policy. For example, retrieving HR records should remain outside a customer-support agent’s remit even if its tools can reach them.

For a payments-service alert, an orchestrator can propose an investigation. An authorization service checks the authenticated trigger, the agent’s permitted role and policy set outside its control, then grants an incident agent read access to that service’s logs from the previous hour. If evidence points to an authentication service, the agent requests those logs; policy can allow access automatically or require human approval, but runtime blocks the request until approval is granted. The agent may follow the lead without deciding its own permissions.

When the incident agent delegates log analysis, the receiving agent uses its own verifiable identity and receives only the access needed for its part of the task, within its own permissions. The handoff may narrow the existing grant but cannot expand it, and preserves task context and a record of who passed it along. Authorization must also separate trusted context from untrusted content: an authenticated alert may contain an attacker-written log line, and the alert’s trusted source does not make instructions inside that line valid authorization.

In a software factory, an orchestrator may monitor incidents and scanner findings, select bugs without tickets and dispatch agents to investigate and propose fixes. Finding useful tasks does not authorize it to assign any access they require; an independent decision must set limits that are enforced while agents run. Budgets can constrain excessive requests, while checks and tests determine which changes advance. Audit records kept outside the agent preserve what happened, and revocable access lets operators stop activity when needed.

The Software Factory reference architecture, developed by Keycard, Docker, Barclays, Socket and Aaron Stanley on Agent Baseline, defines four boundaries: identity and access, supply chain, sandbox and network. They cover task-scoped access, the software agents use, where they execute and which systems they can reach. The design allows agents to choose what to investigate next while keeping access decisions under independent control.

Coding agents investigating production bugs may need to read repositories, query logs and open pull requests. When a lead points to another service, access depends on the investigation, but credentials often grant the same permissions regardless of the task. API keys and tokens usually do not record what the agent was asked to do, who assigned the work or how it arrived. Intent-based authorization uses that purpose and context to assess each access request against the assigner’s permissions, the agent’s role and organizational policy. For example, retrieving HR records should remain outside a customer-support agent’s remit even if its tools can reach them.

For a payments-service alert, an orchestrator can propose an investigation. An authorization service checks the authenticated trigger, the agent’s permitted role and policy set outside its control, then grants an incident agent read access to that service’s logs from the previous hour. If evidence points to an authentication service, the agent requests those logs; policy can allow access automatically or require human approval, but runtime blocks the request until approval is granted. The agent may follow the lead without deciding its own permissions.

When the incident agent delegates log analysis, the receiving agent uses its own verifiable identity and receives only the access needed for its part of the task, within its own permissions. The handoff may narrow the existing grant but cannot expand it, and preserves task context and a record of who passed it along. Authorization must also separate trusted context from untrusted content: an authenticated alert may contain an attacker-written log line, and the alert’s trusted source does not make instructions inside that line valid authorization.

In a software factory, an orchestrator may monitor incidents and scanner findings, select bugs without tickets and dispatch agents to investigate and propose fixes. Finding useful tasks does not authorize it to assign any access they require; an independent decision must set limits that are enforced while agents run. Budgets can constrain excessive requests, while checks and tests determine which changes advance. Audit records kept outside the agent preserve what happened, and revocable access lets operators stop activity when needed.

The Software Factory reference architecture, developed by Keycard, Docker, Barclays, Socket and Aaron Stanley on Agent Baseline, defines four boundaries: identity and access, supply chain, sandbox and network. They cover task-scoped access, the software agents use, where they execute and which systems they can reach. The design allows agents to choose what to investigate next while keeping access decisions under independent control.