Introduction
Applied example
This example shows how aws2 can be applied to one scoped workflow. It is deliberately narrow: a release-assistant agent that helps an engineering team prepare release notes and internal change summaries.
Workflow
The agent reads selected tickets, pull requests, changelog fragments, and test results. It drafts a release summary, prepares an internal ticket update, and suggests a customer-facing note that a human must approve before use.
The agent is not allowed to deploy code, change production configuration, send external messages, modify customer records, or read unrelated repositories.
Boundary
| Boundary item | Example scope |
|---|---|
| Runtime | One approved agent runtime for release-assistant work. |
| Repositories | Two product repositories and their release branches. |
| Documents | Release-planning folder and approved changelog folder. |
| Tickets | One release project in the issue tracker. |
| Shell access | Read-only test and metadata commands in a controlled workspace. |
| Communication | Draft-only internal update and draft-only customer note. |
| Exclusions | Production deployment, customer database access, unrelated repositories, direct external sending, and permission changes. |
Reach
The profile should list what the agent can read or invoke:
- selected repository paths
- selected ticket fields
- release-planning documents
- test-result artifacts
- approved shell commands
- approved draft-message tools
Anything nearby but outside the workflow should be named as excluded. A clear exclusion is useful evidence. A hidden exclusion weakens the review.
Authority
The workflow should identify the authority path:
| Action | Authority model |
|---|---|
| Read release documents | Delegated team workspace access. |
| Read selected repositories | Repository read access scoped to release branches. |
| Run allowed test-summary commands | Runtime-mediated command policy. |
| Draft internal update | Draft-only tool permission. |
| Draft customer note | Draft-only permission with human approval required before sending. |
The profile should say whether the agent acts through a user session, workflow identity, service account, connector identity, or another authority path.
Actions and approvals
The workflow can separate low-impact work from high-impact work.
| Action class | Policy |
|---|---|
| Read selected files and tickets | Allowed inside the named boundary. |
| Run approved summary commands | Allowed if command and working directory match policy. |
| Draft internal release update | Allowed as draft. |
| Draft customer-facing note | Must pause for human approval before use. |
| Send external message | Out of scope or denied. |
| Deploy code or change production configuration | Out of scope or denied. |
| Export sensitive data | Denied unless separately approved and logged. |
The important point is that approval rules are defined before the workflow runs, not reconstructed after something goes wrong.
Evidence
The evidence packet does not need to copy every private file or transcript. It should keep redaction-safe records that explain important actions.
Useful evidence may include:
- scope record and exclusion list
- runtime policy version
- repository and document inventory summary
- allowed command list
- draft-message approval record
- denied-action records
- source and tool version record
- validation findings and retest notes
- exception register
The evidence should help reviewers understand what happened without becoming a new sensitive-data leak.
Findings and exceptions
The profile may find gaps. For example:
| Finding | Decision |
|---|---|
| Shell policy is described but not enforced by runtime controls. | Keep workflow in internal review only until runtime enforcement exists. |
| Draft customer note approval is manual and not attached to the action receipt. | Add approval receipt requirement before customer-facing use. |
| Repository inventory is current but document-folder inventory is manual. | Accept time-limited exception with owner and review date. |
| Denied external-send action is logged without payload. | Accept if event ID, actor, policy outcome, and affected tool are recorded. |
Exceptions should have owners, review dates, and a clear plan to close or accept the gap. The profile should not hide unresolved gaps.
Profile summary
A short summary might read:
The release-assistant workflow maps to selected
aws2candidate controls for scope, delegation, workspace boundary, runtime action control, source trust, sensitive-data handling, logs, validation, and governance. The workflow is suitable for internal review with named exceptions.
That summary is useful because it ties the review to one named workflow, selected controls, evidence, and known exceptions.