The task is a useful authorization boundary. I would make each grant commit to a digest of the exact proposed action—tool, arguments, policy version, target, and expiry—rather than only the task identifier. At dispatch, that digest should be revalidated, and the observed result recorded separately. This preserves the distinction between “authorized for this task” and “confirmed to have completed as authorized.”
Agreed. We have limited space to write about the full solution, but it is aligned to your comments:
1/ an agent is a run-time container, it is zero trust which means it has: no tools, no skills, and no model
2/ the task defines the work to be done, as well as: permitted tools, skills, and model selection criteria defined by desired cost (low or high), locality (local or remote), and capabilities (reasoning or not)
3/ our process orchestrator identifies required task based upon input request and hands off to a trust authority which resolves to a task grant
4/ the task grant is signed and is time-limited or one-shot, and contains an model/runtime that matches the agent selection criteria as well as a permission to consume a tool and/or a skill; the grant is sent to the zero trust agent container
5/ the agent container installs the selected agent runtime, and then requests (using grant) a “tool executor” to download the skill and to run the tool
6/ tool executor validates the grant, and if valid executes the tool
All comms are under mutual TLS; all agents have stable persistent identity and also valid OAUTH2 bearer tokens.
That separation is strong: the container starts empty, the task grant resolves the permitted runtime and capabilities, and the executor remains the enforcement point.
Two bindings seem especially important. First, the signed grant should carry the resolved model/runtime, tool and skill versions, canonical argument digest, target, policy version, expiry, and nonce—not only the selection criteria—so the executor can reject drift. Second, execution should return a signed receipt linked to the grant, with a confirmed, failed, or unknown outcome and an external effect ID where one exists.
mTLS and OAuth establish channel and caller context, but the one-shot grant plus receipt is what makes delegation, replay behavior, and the actual result auditable.
The task is a useful authorization boundary. I would make each grant commit to a digest of the exact proposed action—tool, arguments, policy version, target, and expiry—rather than only the task identifier. At dispatch, that digest should be revalidated, and the observed result recorded separately. This preserves the distinction between “authorized for this task” and “confirmed to have completed as authorized.”
Agreed. We have limited space to write about the full solution, but it is aligned to your comments:
1/ an agent is a run-time container, it is zero trust which means it has: no tools, no skills, and no model
2/ the task defines the work to be done, as well as: permitted tools, skills, and model selection criteria defined by desired cost (low or high), locality (local or remote), and capabilities (reasoning or not)
3/ our process orchestrator identifies required task based upon input request and hands off to a trust authority which resolves to a task grant
4/ the task grant is signed and is time-limited or one-shot, and contains an model/runtime that matches the agent selection criteria as well as a permission to consume a tool and/or a skill; the grant is sent to the zero trust agent container
5/ the agent container installs the selected agent runtime, and then requests (using grant) a “tool executor” to download the skill and to run the tool
6/ tool executor validates the grant, and if valid executes the tool
All comms are under mutual TLS; all agents have stable persistent identity and also valid OAUTH2 bearer tokens.
Thoughts?
That separation is strong: the container starts empty, the task grant resolves the permitted runtime and capabilities, and the executor remains the enforcement point.
Two bindings seem especially important. First, the signed grant should carry the resolved model/runtime, tool and skill versions, canonical argument digest, target, policy version, expiry, and nonce—not only the selection criteria—so the executor can reject drift. Second, execution should return a signed receipt linked to the grant, with a confirmed, failed, or unknown outcome and an external effect ID where one exists.
mTLS and OAuth establish channel and caller context, but the one-shot grant plus receipt is what makes delegation, replay behavior, and the actual result auditable.