Add Authority Ops hackathon application + red-team hardening

.github/workflows/authority-ops.yml

@@ -0,0 +1,30 @@
+name: Authority Ops
+
+on:
+  push:
+    branches: [main, hackathon-authority-ops]
+    paths:
+      - 'hackathon/authority-ops/**'
+      - '.github/workflows/authority-ops.yml'
+  pull_request:
+    paths:
+      - 'hackathon/authority-ops/**'
+      - '.github/workflows/authority-ops.yml'
+
+jobs:
+  test:
+    runs-on: ubuntu-latest
+    defaults:
+      run:
+        working-directory: hackathon/authority-ops
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 22
+          cache: npm
+          cache-dependency-path: hackathon/authority-ops/package.json
+      - run: npm install --no-audit --no-fund
+      - run: npm run build
+      - run: npm test
+      - run: npm run demo

hackathon/authority-ops/ABOUT-PROJECT.md

@@ -0,0 +1,62 @@
+# Authority Ops — About the Project
+
+## What is Authority Ops?
+
+Authority Ops is a professional AI agent for invoice processing and simulated payments. It is designed around a simple operational rule: an agent may propose an action, but the agent does not get to decide its own authority.
+
+The agent processes invoices, proposes payment actions, and requests execution through an explicit authority layer. The authority contract defines what the agent may do, when human approval is required, and what must be blocked.
+
+## Who is it for?
+
+Authority Ops is designed for finance and operations teams that want to automate repetitive invoice work without giving an AI agent unrestricted permission to move money or operate business systems.
+
+The demonstrated workflow uses three tiers:
+
+- **$0–$500:** autonomous approval and simulated execution
+- **$501–$1,000:** human approval required
+- **Above $1,000:** denied before payment execution
+
+## Why does it matter?
+
+Traditional automation often focuses on whether a tool can perform an action. Agentic systems add a different problem: the model can reason about actions and choose tools dynamically.
+
+Authority Ops makes the missing boundary explicit:
+
+> **Proposal ≠ Authorization ≠ Execution ≠ Outcome**
+
+The result is an agent workflow where permission is evaluated independently from model reasoning, execution occurs only after authorization, and the system records evidence of what was requested and what happened.
+
+## How it works
+
+1. A Strands agent reads and reasons about an invoice.
+2. The application derives transaction-critical fields from trusted invoice state.
+3. The proposed payment action is evaluated by an Agent Authority integration using Passport, Contract, Gate, and Authority Score concepts.
+4. The gate returns **ALLOW**, **ASK**, or **DENY**.
+5. Only an authorized action may reach the simulated payment executor.
+6. The workflow records an evidence chain covering request, evidence, proposal, authorization, approval, execution attempt, destination, and outcome.
+
+The implementation also includes regression tests for wrong-agent identity, authority-limit violations, invoice-context substitution, destination substitution, and action-digest integrity.
+
+## What was built for the hackathon
+
+Authority Ops is a new application built for the Agents for Humans Hackathon. It uses the existing open-source Agent Authority project as an authority-layer integration. The new application work includes the invoice workflow, Strands agent/tool integration, scenario data, browser UI, evidence-flow implementation, and red-team hardening.
+
+The payment flow is simulated. This is a hackathon reference application, not a production payment system or a hardened financial execution environment.
+
+## Built with
+
+- **Strands Agents TypeScript SDK** — agent orchestration, tool use, and model-driven workflow
+- **Amazon Bedrock** — model provider for the live agent path
+- **TypeScript / Node.js 22+** — application runtime
+- **Agent Authority** — identity, delegated contracts, policy gates, authority scoring, and signed/evidence-oriented authorization concepts
+- **Zod** — TypeScript schema validation
+- **HTML / CSS / JavaScript** — browser presentation interface
+- **GitHub Actions** — automated build and deterministic demo/test workflow
+
+## Track
+
+**Professional Agents** — an agent intended to make repetitive, judgment-heavy professional work faster while keeping consequential actions inside explicit authority boundaries.
+
+## License
+
+MIT

hackathon/authority-ops/AWS-BUILDER-BLOG-DRAFT.md

@@ -0,0 +1,70 @@
+# Agents for Humans: Building an Authority-Aware Professional Agent with Strands Agents
+
+## Working thesis
+
+AI agents are good at proposing actions. Professional software needs a separate answer to a harder question: **is this exact action authorized?**
+
+For the Agents for Humans Hackathon, Authority Ops explores that boundary in a concrete accounts-payable workflow using Strands Agents for the agent layer and an explicit delegated-authority layer for transaction control.
+
+## The use case
+
+Imagine a finance team that wants an AI agent to process routine vendor invoices.
+
+The agent should be able to read an invoice, identify the vendor and amount, and request a payment. But the organization does not want the model to decide its own authority.
+
+Our demo contract therefore defines three tiers:
+
+- $500 or less: autonomous execution
+- $501–$1,000: human review
+- above $1,000: deny
+
+This turns an abstract safety principle into a visible business rule.
+
+## Why Strands Agents
+
+The application is implemented in TypeScript using the Strands Agents SDK. Strands provides the agent loop, model interaction, and custom tool mechanism; the authority layer remains an explicit application boundary around the business action.
+
+The important architectural choice is that the payment capability is not trusted merely because the model selected a tool. The application constructs the payment request from trusted invoice state and then asks the authority gate to evaluate that exact request.
+
+## The security lesson
+
+During development we deliberately tested an obvious failure mode: could an untrusted caller change the invoice amount and turn an $8,400 invoice into a $400 authorized payment?
+
+The first implementation exposed this weakness because the tool accepted an agent-supplied transaction amount.
+
+We hardened the flow so the payment request is derived from trusted application state using the invoice ID supplied to the tool. The same principle applies to vendor, currency, invoice ID, and destination.
+
+We also tested destination substitution: an authorized payment must not become authorized merely because its destination changes.
+
+The result is a stronger boundary:
+
+**model proposal → trusted application state → authorization decision → execution**
+
+## Evidence, not just logs
+
+The demo records a causal evidence chain:
+
+**REQUEST → EVIDENCE → PROPOSAL → AUTHORIZATION → APPROVAL → EXECUTION ATTEMPT → DESTINATION → OUTCOME**
+
+This distinction matters because a model response saying "pay the invoice" is not proof that an authorized payment happened.
+
+## What the demo shows
+
+1. A $480 invoice is allowed and submitted to the simulated payment system.
+2. An $800 invoice enters the human-approval path and is submitted after approval.
+3. An $8,400 invoice is denied before payment execution.
+4. Red-team tests verify identity binding, amount binding, destination binding, and digest integrity.
+
+## What comes next
+
+The hackathon application is deliberately small. A production system would need durable state, stronger issuer trust, real human-approval infrastructure, hardened runtime isolation, real financial controls, and independent security review.
+
+The architectural idea is the part worth carrying forward: **an agent should not be its own authority boundary.**
+
+## Suggested closing
+
+Strands makes it easy to build an agent that can reason and act. Authority Ops asks what should happen one layer later:
+
+> When the agent proposes an action, what proves it was allowed to perform that exact action?
+
+That is the boundary we built and tested for this hackathon.

hackathon/authority-ops/HACKATHON-SUBMISSION.md

@@ -0,0 +1,209 @@
+# Authority Ops — Submission Package
+
+## One-line pitch
+
+**Give a professional AI agent a permission slip—and make every attempted action prove what it was allowed to do.**
+
+## Project title
+
+Authority Ops
+
+## Track
+
+Professional Agents
+
+## Submission description
+
+### The problem
+
+AI agents are increasingly capable of taking actions inside business workflows, but capability is not the same thing as authorization. In accounts payable, an agent may correctly identify an invoice and propose a payment while still having no authority to move that amount, use that destination, or act without human review.
+
+Traditional demos often blur together what the model proposed, what the system permitted, what the tool executed, and what actually happened. That makes an agent difficult to trust.
+
+### Who it is for
+
+Authority Ops is designed for finance, operations, and IT teams that want AI agents to handle repetitive invoice workflows without giving those agents unrestricted transaction power.
+
+### What it does
+
+Authority Ops uses a Strands Agents TypeScript agent to process invoices and request simulated payments. Before execution, an explicit authority layer evaluates the action against the agent's identity and delegated contract.
+
+The demo contract creates three visible outcomes:
+
+- **$500 or less → ALLOW** — execute automatically.
+- **$501–$1,000 → ASK** — require human approval.
+- **Above $1,000 → DENY** — do not execute.
+
+The payment adapter also binds transaction-critical fields—invoice ID, amount, vendor, currency, and destination—to trusted application state instead of accepting those fields from the model as authority-bearing input.
+
+### Why it matters
+
+The design makes a simple but important distinction explicit:
+
+> **Proposal is not authorization. Authorization is not execution. Execution is not outcome.**
+
+The resulting evidence chain records the causal path:
+
+**REQUEST → EVIDENCE → PROPOSAL → AUTHORIZATION → APPROVAL → EXECUTION ATTEMPT → DESTINATION → OUTCOME**
+
+That pattern can be applied to other professional agents that need bounded, reviewable action authority.
+
+### What makes it different
+
+Authority Ops does not replace the agent framework. Strands handles the agent loop, reasoning, and tool use. The authority layer sits at the action boundary and evaluates whether a proposed operation is permitted before the business tool runs.
+
+The demo therefore focuses on the control point that is easy to miss in an agent architecture: the transition from **"the agent wants to do this"** to **"the system permits this exact action."**
+
+### AWS / Strands implementation
+
+The application is implemented in TypeScript with `@strands-agents/sdk` and includes a live Amazon Bedrock path using `BedrockModel`. A deterministic local path is also provided so judges can reproduce the core behavior without cloud credentials.
+
+The project can be built and tested from `hackathon/authority-ops` with Node.js 22+.
+
+### Demonstrated scenarios
+
+| Invoice | Amount | Gate | Outcome |
+| --- | ---: | --- | --- |
+| INV-1041 | $480 | ALLOW | Simulated payment submitted |
+| INV-1042 | $800 | ASK | Approval recorded, then simulated payment submitted |
+| INV-1043 | $8,400 | DENY | Payment execution blocked |
+
+### Security posture
+
+This is a hackathon reference application. Payments are simulated; this is not a production payment system or hardened hostile-code sandbox. The red-team hardening is intentionally included to demonstrate that critical transaction fields must come from trusted business state rather than model-generated values.
+
+## Demo video outline
+
+Target runtime: **4:30–4:50**. Keep the final upload below the 5-minute maximum.
+
+### 0:00–0:20 — Hook
+
+Show INV-1043 at $8,400.
+
+Say:
+
+> "I gave this AI agent authority to approve payments up to $1,000. Now watch what happens when it encounters an $8,400 invoice."
+
+### 0:20–0:50 — Problem
+
+Show the architecture and the three authority tiers.
+
+Say:
+
+> "An agent can know what should happen and still not be authorized to do it. We separate proposal, authorization, execution, and outcome so the boundary is enforceable and observable."
+
+### 0:50–1:20 — Architecture
+
+Highlight:
+
+**Strands Agent → Passport / Contract / Gate → business tool → Ledger**
+
+Explain that the payment tool is downstream of the authority decision.
+
+### 1:20–2:15 — ALLOW case
+
+Run INV-1041 ($480).
+
+Show:
+
+**ALLOW → simulated execution → receipt**
+
+Point out that the amount and destination are bound by trusted application state.
+
+### 2:15–3:10 — ASK case
+
+Run INV-1042 ($800).
+
+Show:
+
+**ASK → human approval → simulated execution → receipt**
+
+Pause briefly on the approval record.
+
+### 3:10–3:45 — DENY case
+
+Run INV-1043 ($8,400).
+
+Show:
+
+**DENY → payment tool not invoked**
+
+Say:
+
+> "The agent can propose the payment. It cannot grant itself the authority to execute it."
+
+### 3:45–4:20 — Red-team proof
+
+Show the test output for:
+
+- wrong agent identity
+- trusted invoice amount binding
+- destination substitution
+- action digest integrity
+
+Say:
+
+> "We deliberately attacked the boundary during development. A caller cannot turn an $8,400 invoice into a $400 authorized transaction, and an authorized amount cannot be redirected to an unapproved destination."
+
+### 4:20–4:45 — Close
+
+Show the evidence chain.
+
+Say:
+
+> "Authority Ops demonstrates a reusable pattern for professional agents: give agents useful power, constrain that power explicitly, and leave evidence of what was requested, authorized, executed, and produced."
+
+## Judge-facing proof points
+
+### Technical Implementation
+
+- Real Strands Agents TypeScript SDK integration.
+- Amazon Bedrock live path plus deterministic local test path.
+- Custom tools and an explicit action-authorization boundary.
+- Regression tests for identity, authority limits, trusted invoice binding, destination substitution, and action digest integrity.
+
+### Design
+
+- One focused professional workflow.
+- Three easy-to-understand authority outcomes.
+- Browser presentation UI plus CLI demo.
+- Evidence chain makes authorization state visible instead of hiding it in logs.
+
+### Potential Impact
+
+- Targets repetitive accounts-payable work.
+- Demonstrates a concrete pattern for safe delegation instead of a generic chatbot.
+- The authority model is intentionally independent of one business workflow.
+
+### Creativity & Originality
+
+- Treats the authorization boundary itself as a product surface.
+- Makes the distinction between model proposal and executable authority visible.
+- Adds a security-focused red-team story to the demo rather than only showing the happy path.
+
+### Presentation
+
+- Start with the $8,400 denial, not the architecture diagram.
+- Keep the authority policy visible throughout the demo.
+- Show all three outcomes end-to-end.
+- End with evidence, not another model response.
+
+## Final pre-submission checklist
+
+- [ ] Devpost title: Authority Ops
+- [ ] Track: Professional Agents
+- [ ] Public repository URL added
+- [ ] Repository shows an MIT license
+- [ ] README present and install instructions tested
+- [ ] Architecture diagram linked and visible
+- [ ] Demo video is public and under 5 minutes
+- [ ] Video demonstrates the working project and covers problem, audience, and importance
+- [ ] AWS Builder ID entered
+- [ ] Live demo link added, if stable
+- [ ] Any pre-existing non-standard code/work disclosed
+- [ ] No secrets, credentials, or private data in the repository
+- [ ] Final submission submitted before September 14, 2026 at 5:00 PM PDT
+
+## Optional bonus
+
+The official rules allow up to **0.6 bonus points** for public AWS Builder blog posts describing the journey building and implementing AWS for the hackathon. Up to three pieces can contribute 0.2 each; the title must use **Agents for Humans**. 

hackathon/authority-ops/HACKATHON.md

@@ -0,0 +1,7 @@
+# Hackathon project disclosure
+
+Authority Ops is the new application submitted for the Agents for Humans Hackathon.
+
+The application uses the Agent Authority protocol as an authority-layer integration. Agent Authority remains a separate open-source project.
+
+The new work in this application is the professional invoice workflow, Strands agent/tool integration, scenario data, UI, and evidence-flow implementation.