After stage 7

What you just learned

If you can say this in your own words, the lab worked.

An AI agent sometimes needs to pass work to another agent. The second agent should get only the access that piece of work requires, and it should not be able to give itself or anyone else more access than it received.

And if you got further than that:

An agent's identity tells you which agent is acting. It does not tell you what that agent was allowed to do for this particular job.

Those are the two principles the challenge was built to make concrete.

Why Tenuo fits this problem

Each earlier approach improved one part of the system. The lab also showed what remained when agents had to pass changing, job-specific authority to one another.

Approach	What the lab showed
Shared credential	Simple, but one fooled agent gets the authority of the whole system.
Identity and roles	Reduce the blast radius, but describe the agent's general job rather than the specific task.
Detailed central policy	Can enforce task-specific rules, but needs current shared state during the work and does not make safe delegation automatic.
Tenuo warrants	Carry the task's authority with the work, can only narrow at each handoff, are bound to the receiving agent's key, and are checked beside the tool without a runtime central call.

The conclusion: for dynamic, multi-hop agent delegation, Tenuo is the best fit of the approaches exercised here because least privilege survives every handoff without putting a central service on every tool call.

Tenuo complements workload identity, key management, and policy design; it supplies the delegation layer those systems do not provide on their own. A control plane is still needed to issue the first warrant for new work.

Here are the technical terms, now that you have the ideas they attach to.

Term	Where you met it
Ambient authority	Stage 1. Permission that follows the agent everywhere instead of following the job.
Identity-based access control	Stage 2. Permissions attached to who is acting.
Confused deputy	Stage 4. An agent with real authority being steered into using it for the wrong job.
Central authorization	Stage 4. A registry or policy service that every check depends on for current task context.
Delegation	Stage 4. Passing work, and the access for it, to another agent.
Privilege escalation	Stage 4. Ending up with more access than you were given.
Attenuation	Stage 5. Access that can narrow when it is passed on, and can never widen.
Capability	Stage 5. Permission carried by the request rather than looked up about the requester.
Trust root	Stage 5. The one key that can sign a fresh permission, and that no agent holds.
Holder binding	Stage 6. A permission that only works for whoever it was issued to.
Prompt injection	The whole lab. Instructions hidden in data that an agent reads and follows.

Going further

The authorization system you used in stages 5 to 7 is open source at github.com/tenuo-ai/tenuo. The delegation rules behind it are being standardized in the public IETF draft on attenuating agent tokens. A star on the repository is the main way maintainers find out anyone is using their work.

npm run star       # optional: support the project without changing screens
npm run share      # send Tenuo a redacted scorecard
npm run share -- --username YOUR_GITHUB_USERNAME
                   # optional: use this unverified name on future leaderboards

Sharing is explicit. Tenuo receives the star results, attempt count, redacted first-attempt and first-green summaries, a random local challenge-session ID, and runtime versions. It never receives source, keys, argument values, filesystem paths, or client timestamps. The same scorecard is saved locally, and a failed delivery is clearly reported.