Define the engineering task before granting tools

TL;DR: Translate the maintenance request into a versioned grant that identifies the actor, project, permitted effects, data audiences and limits. Preparing a patch, executing tests and publishing a review bundle are different authorities. Continue useful work within the grant; obtain a new decision only when the actual effect requires it.

Where you are. Module one, lesson one. You will create the task contract and authority map used throughout the engineering-agent review packet.

The case: fix a rendering defect in CedarDocs

CedarDocs is a fictional documentation repository in project Cedar. Its owner, Priya, asks an agent to diagnose a rendering defect, prepare a patch and assemble evidence for review. Another project, Flint, shares some infrastructure but has a different audience. All records and numbers in this course are synthetic teaching fixtures.

The agent can inspect selected Cedar documents and source files, propose changes and request a designated isolated test service. It cannot read secrets, change its policy or deployment configuration, access Flint, or publish a production release. A later lesson adds a separate grant for publishing an approved review bundle to the Cedar review workspace. That grant does not authorize deploying the patch.

Save the outputs as one packet: task contract, delegation map, workspace-change contract, execution ledger, memory publication rule, recovery plan, evaluation and release memo. Each lesson changes one part of this system and asks whether the previous decision still holds.

Translate the request into observable effects

“Fix the defect” is a useful objective, but it leaves several operational decisions unstated. The agent may need to read source files, create a proposed patch and run permitted tests. Those intermediate steps can be covered without requiring Priya to approve every read. Publishing a release or expanding into a different project is a different outcome.

Write the effect before choosing a tool. A shell is a mechanism that may enable many effects; a service returning a bounded patch proposal can have a much smaller reachable scope. Conversely, a tool called preview may write files or upload content. Review what the tool actually does, including helpers, caches and callbacks.

For this exercise, the task service records grant G-1 for task T-17. The service is the controlled source of the grant. Priya's authenticated request and current project authority justify its creation. A note inside the repository claiming broader permission does not.

The resource and budget values in this memo are exercise constraints, not recommended production settings. A real owner chooses limits from supported workflows and resource costs, then tests concurrent and failure behavior. The initial contract makes those decisions visible so later lessons can examine them.

Name the actor and the data audience separately

Priya can authorize maintenance within Cedar. The agent authenticates as its own workload and carries the task grant; it does not become Priya in every system. The order of checks is therefore not simply “Priya can read it.” The resource service must establish that this worker, for this current task, may access the selected resource and fields.

The evidence may also travel to a model processor, a test service, a reviewer, a log store or a memory collection. Record each intended audience. A permitted source read does not automatically permit uploading the full repository to any model endpoint or sharing a private debugging note with Flint.

For the course, the processing services and Cedar review workspace are approved audiences for the specified material. That is a case assumption to verify in a real review, not a property supplied by the word “internal.” Keep secret and unrelated project data out of the task context in the first place.

A service-owned nightly maintenance task would use a governed service grant with an accountable owner. It need not invent a human user behind every run. Its authority still needs a scope, current policy and an execution identity; a broad service credential is not a substitute for the task contract.

Make revision a controlled operation

Suppose Priya later asks to post the finished review bundle to Cedar's review workspace. The task service can record G-2 with the actual bundle version, destination and permitted publication effect after checking her authority and policy. The original G-1 remains evidence of what was allowed earlier.

A proposed change of scope is not itself misconduct. The critical distinction is whether the agent requests a decision or silently treats its own plan as permission. An existing grant also does not vanish whenever the agent encounters uncertainty in a document. Continue independent covered steps while resolving the disputed fact or effect.

At execution, use the currently valid grant and business policy. A queued job cannot restore authority simply by carrying an old grant reference. Later lessons will add revocation, reservations and uncertain outcomes so that this rule holds across retries and resumed work.

Review the paths that could bypass the contract

List every route to a meaningful effect. Can the reader call the publication service directly? Can a test worker reach a credential endpoint? Can a proposed patch change the configuration that chooses tool permissions? Can a shared cache return Flint content under a Cedar task?

The map should show an enforcement owner for each boundary. Task creation belongs to the task service, object access to the resource service, test execution to the isolated runner and publication to the release gate. The model can propose and explain; the controlled services resolve identities, policy facts and effects.

A diagram cannot establish that these paths are enforced. Mark each claim as a design requirement, implemented check or tested observation. This distinction will matter in the final release decision, where some requirements still lack evidence.

Do this before moving on

Create a six-row decision table for T-17: read the designated renderer, inspect Flint's private notes, propose a change to the Cedar guide, modify the agent's permission configuration, request the approved isolated test service, and publish the review bundle before G-2 exists. For each, identify the required grant and the service that must enforce the decision.

Worked feedback. G-1 covers the designated read, bounded patch proposal and approved test-service request, subject to current limits. Flint access and permission changes are outside the contract. Publication requires its separate authority; a successful patch does not supply it. A good answer also checks what data the test request sends and distinguishes preparing a proposal from committing it to a live workspace.

Add two assumptions you would verify before a pilot. Useful choices include whether every worker must pass through the resource gateway and whether the test service is isolated from production credentials. A requirement written in the memo is not yet evidence that it holds.

Go deeper

• Agentic AI security explains the identities, inputs and reachable effects behind the task map.

• Tool permission design turns the map into checks at each resource boundary.

• Agent autonomy policy distinguishes covered work from new decisions and prohibited effects.

• Scope drift tests legitimate task revisions against attempts to expand authority.

• Excessive agency distinguishes necessary functionality, permissions and autonomy for the contract.

Key takeaways

• Define permitted effects, resources, audiences and limits before selecting tools.
• Workload identity and a user's project access do not replace a current task grant.
• Source content can provide evidence but cannot grant new authority.
• Distinguish designed requirements from implemented and tested boundaries.