@nullsquare/agent-authority 0.4.6 → 0.4.8

package/docs/product-proof.md

@@ -71,13 +71,137 @@ Do not prioritize another deep authorization subsystem until the following are d
 
 - [ ] a new developer can run a meaningful task-first example in under 10 minutes;
 - [ ] at least three real workflow examples exist: coding, support/communications, and operations/finance;
-- [ ] the same task-first API works in-memory and with durable local state;
-- [ ] useful-task completion stays high under the product benchmark;
-- [ ] normal task actions do not trigger unnecessary approvals;
-- [ ] unrelated-resource effects execute zero provider callbacks;
-- [ ] approval/step-up output explains the established authority and requested delta clearly;
+- [x] the same task-first API works in-memory and with durable local state;
+- [x] useful-task completion stays high under the deterministic product benchmark;
+- [x] normal fixture task actions do not trigger unnecessary approvals;
+- [x] unrelated-resource effects execute zero provider callbacks in the deterministic fixture, live GitHub proof, support/communications proof, and operations/finance proof;
+- [x] approval/step-up output explains the established authority and requested delta clearly;
 - [ ] at least one external developer uses the package without project-author assistance.
 
+The checked utility items are evidence about the current deterministic fixtures and live GitHub proof, not a claim that arbitrary real-world agent workloads have already met the same rates.
+
+## First live provider product proof
+
+The existing GitHub Actions mutation validation now runs through the public task-first API rather than hand-assembling Mission + Task Lease + Guard.
+
+The live workflow uses:
+
+```text
+createTask()
+   |
+   v
+task.run(issue.list)
+   |
+   v
+task.authorityFrom(reviewed GitHub output)
+   |
+   v
+issue #9 becomes downstream task authority
+   |
+   +--> task.run(issue.comment #9) -> real GitHub mutation
+   +--> task.run(issue.comment #1) -> STEP-UP, zero provider mutation
+   |
+   v
+task.complete()
+   |
+   v
+issue.comment #9 -> DENY, zero provider mutation
+```
+
+Passing CI evidence from the live run:
+
+- repository root: `Null-Square/agent-authority`;
+- reviewed fixture selection: issue `#9`;
+- `task.authorityFrom()` established issue `#9` as downstream authority;
+- exactly one real GitHub comment mutation executed;
+- unrelated issue `#1` produced `authority_delta_required` before provider mutation;
+- `task.explain()` reported established authority `9` vs requested value `1`;
+- the same issue was denied after `task.complete()`;
+- provider calls before cleanup: `reads=1`, `task_mutations=1`;
+- the temporary validation comment was deleted outside the authority proof.
+
+This establishes a real-provider product proof for the facade, but it is **not yet** the full coding-agent product workflow. Branch creation, file edits and PR creation still need to be chained under task-derived authority while merge/deploy remain outside the task.
+
+## Cross-provider support/communications proof
+
+`examples/task-first-support.js` exercises the same public facade across two service boundaries using the exact field names and normalized sender shape used by the Google adapter:
+
+```text
+Task: handle one customer email and schedule the requested meeting
+
+origin thread authority
+      |
+      v
+task.run(gmail:thread.read)
+      |
+      v
+reviewed Gmail sender extractor
+      |
+      v
+customer@example.com
+      |
+      v
+task.bind(calendar:event.create.attendee_email)
+      |
+      +--> exact customer meeting -> ALLOW
+      +--> unrelated attendee -> STEP-UP, zero Calendar callbacks
+      |
+      v
+task.complete() -> same meeting authority no longer usable
+```
+
+The task also binds the Gmail `thread_id` and Calendar `calendar_id` to explicit task-entry roots. A different Gmail thread is stopped before its callback runs.
+
+The example and `test/task-product-support.test.js` run on Node 20 and Node 22 CI. The support proof demonstrates that the task-first model crosses Gmail -> Calendar without a second authorization abstraction.
+
+This is intentionally a **self-contained product proof**. It mirrors the real Google provider contract but does not close the separate public Google Actions evidence gate; that gate still requires repository OAuth secrets.
+
+## Operations / finance lineage proof
+
+`examples/task-first-finance.js` exercises a longer evidence-derived authority chain without adding another provider, policy DSL, or numeric relation language:
+
+```text
+Task: resolve one support ticket by refunding only its payment
+
+ticket:481
+   |
+   v
+task.run(helpdesk:ticket.read)
+   |
+   v
+order:991
+   |
+   v
+task.run(orders:order.read)
+   |
+   v
+payment:abc123
+   |
+   v
+task.run(payments:payment.read)
+   |
+   +--> amount = 12500 minor units
+   +--> currency = USD
+   |
+   v
+task.bind(refund payment_id + amount + currency)
+   |
+   +--> exact full refund -> ALLOW
+   +--> another payment -> STEP-UP, zero refund callbacks
+   +--> over-refund -> STEP-UP, zero refund callbacks
+   +--> wrong currency -> STEP-UP, zero refund callbacks
+   +--> partial refund -> STEP-UP under current exact binding model
+   |
+   v
+task.complete() -> same refund authority no longer usable
+```
+
+The task cannot read an arbitrary order before the ticket establishes the order fact: the unresolved binding fails closed before the order callback runs. The same pattern continues through payment and refund.
+
+The example and `test/task-product-finance.test.js` run on Node 20 and Node 22 CI. On the passing fixture, provider-shaped callbacks are exactly one ticket read, one order read, one payment read and one refund.
+
+This proof intentionally exposes a **product limitation rather than hiding it behind new policy machinery**: Task Lease bindings currently require exact equality. Therefore the payment amount `12500` can authorize an exact `12500` refund, but a legitimate partial refund such as `5000` also produces `authority_delta_required`. A future narrow `requested amount <= evidence-derived payment amount` relation may be justified if real provider/adoption evidence shows partial refunds are needed. Until then, the repository should keep this limitation visible instead of adding a general expression language speculatively.
+
 ## Utility metrics
 
 Security tests remain required, but product work should additionally track:
@@ -102,7 +226,7 @@ true authority-delta step-up rate = 100%
 unauthorized effect rate = 0%
 ```
 
-Real provider/harness benchmarks should replace or supplement the fixture as the product matures.
+The current fixture run contains 40 normal tasks and 10 unrelated-resource attempts. Real provider/harness benchmarks should replace or supplement it as the product matures.
 
 ## Three product proofs
 
@@ -120,6 +244,8 @@ repository -> issue -> task branch -> changed files -> pull request
 
 Unrelated repositories, issues, merge and deploy remain outside the task.
 
+The live issue-discovery -> exact-issue-comment proof is the first slice of this direction; it does not complete the branch/files/PR lineage yet.
+
 ### Support / communications agent
 
 Task:
@@ -132,7 +258,7 @@ Desired authority lineage:
 email thread -> customer -> meeting / CRM record / reply target
 ```
 
-The underlying connected account may have broad access; task authority follows only the customer/resource discovered through the authorized thread.
+The self-contained Gmail-thread -> exact Calendar-attendee slice is now established. The next value proof should connect the same customer authority to another useful downstream action (for example reply/CRM) or rerun the task-first flow with the real Google Actions fixture once repository OAuth secrets are available.
 
 ### Operations / finance agent
 
@@ -146,7 +272,7 @@ Desired authority lineage:
 ticket -> customer -> order -> payment -> refund <= original payment
 ```
 
-This is the strongest long-term proof because it combines resource lineage with an amount ceiling.
+The self-contained ticket -> order -> payment -> **exact full refund** lineage is now established. The remaining product question is narrower than the original workflow: whether partial refunds are important enough to justify one evidence-derived numeric ceiling relation. Current exact bindings intentionally step up for a smaller amount rather than guessing that relation into the core.
 
 ## Freeze list
 

package/docs/quickstart.md

@@ -0,0 +1,147 @@
+# Fresh-install quickstart
+
+This quickstart is for a developer who wants to understand Agent Authority before connecting an account or learning Mission/Task Lease internals.
+
+It uses the real public task-first API and the reviewed GitHub issue-number authority extractor from the published npm package. The first provider callback is a local provider-shaped fixture, so **no GitHub token, OAuth setup, repository checkout, or custom extractor is required**.
+
+## 1. Create a blank project
+
+```bash
+mkdir agent-authority-quickstart
+cd agent-authority-quickstart
+npm init -y
+npm install @nullsquare/agent-authority
+```
+
+Requires Node.js 20+.
+
+## 2. Get the credential-free fixture quickstart
+
+Download or copy `examples/quickstart.mjs` from this repository into the blank project as `quickstart.mjs`.
+
+For example on macOS/Linux:
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/Null-Square/agent-authority/main/examples/quickstart.mjs -o quickstart.mjs
+```
+
+The file imports only published package exports:
+
+```js
+import { createTask } from '@nullsquare/agent-authority/task';
+import { AuthorityApprovalRequiredError } from '@nullsquare/agent-authority/guard';
+import { githubIssueListSelectedNumberAuthorityExtractor } from '@nullsquare/agent-authority/providers/github';
+```
+
+## 3. Run it
+
+```bash
+node quickstart.mjs
+```
+
+Expected shape:
+
+```text
+ALLOW -> task discovered issue #42 and the exact comment effect ran
+STEP-UP -> The task established authority for 42 but this action requested 7.
+PASS -> useful task work ran; unrelated standing permission did not become task authority
+```
+
+## What happened
+
+The task starts with authority over one repository and one task-selection marker:
+
+```text
+repository + marker
+      |
+      v
+authorized issue discovery
+      |
+      v
+reviewed extractor + execution evidence
+      |
+      v
+issue #42 becomes downstream task authority
+      |
+      +--> comment on #42 -> ALLOW
+      +--> comment on #7  -> STEP-UP before callback
+```
+
+The important point is not the fixture itself. It is that the callback which represents the provider effect executes for the task-derived issue and does **not** execute for the unrelated issue even though the Mission-level GitHub permission includes `issue.comment`.
+
+The quickstart counts callbacks and fails if the unrelated effect executes.
+
+## 4. Next step: call real GitHub with no credential
+
+The second quickstart uses the same published package in the same blank project, but the callback now makes a real network request to GitHub's public API.
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/Null-Square/agent-authority/main/examples/quickstart-github-live.mjs -o quickstart-github-live.mjs
+node quickstart-github-live.mjs
+```
+
+Default behavior:
+
+```text
+Standing GitHub permission -> repo.read
+Task authority -> Null-Square/agent-authority
+GitHub mode -> public API; no credential required
+ALLOW -> real GitHub returned Null-Square/agent-authority
+STEP-UP -> The task established authority for "Null-Square/agent-authority" but this action requested "octocat/Hello-World".
+PASS -> broader standing repo.read permission could not reach an unrelated repository for this task
+```
+
+This example deliberately models the **standing capability as broader than the task**. Mission-level `github:repo.read` is allowed without a repository constraint. The Task authority root then binds `repo.read` to exactly `Null-Square/agent-authority`.
+
+The allowed request performs one real `fetch()` to GitHub. The unrelated repository request reaches the Task authority check, becomes `authority_delta_required`, and does not execute a second `fetch()`.
+
+You can inspect another public repository by passing it as the first argument:
+
+```bash
+node quickstart-github-live.mjs owner/repository
+```
+
+An optional `GITHUB_TOKEN` may be supplied for authenticated GitHub API access, but no token is required for the default public-repository path.
+
+## Replace the fixture with your provider call
+
+The first quickstart's discovery callback is the only intentionally fake provider piece:
+
+```js
+const discovery = await task.run(request, async () => {
+  return providerShapedOutput;
+});
+```
+
+In an application, keep the Agent Authority request and replace the callback with the SDK/provider call you already use. For the built-in GitHub extractor, use the normalized output produced by the Agent Authority GitHub adapter. If your provider/output shape is different, use a reviewed extractor for that mapping rather than trusting arbitrary model-selected values.
+
+The live GitHub quickstart shows the even simpler direct-boundary case: an application can put its existing `fetch()` or SDK call inside `task.run()` while Task authority remains narrower than the standing account/app capability.
+
+## Evidence boundaries
+
+The credential-free fixture is an **adoption quickstart**, not a live-provider security proof. The live GitHub quickstart is a real-provider onboarding proof, but it is read-only and uses a public repository by default.
+
+Separate repository evidence already covers:
+
+- a real GitHub issue discovery -> exact issue comment mutation through the task-first API;
+- Gmail sender -> Calendar attendee authority;
+- SDK, MCP and broker transport invariance;
+- durable local Task Lease recovery/session behavior;
+- adversarial execution-evidence tests.
+
+The public Gmail -> Calendar GitHub Actions proof remains separately gated on repository Google OAuth secrets. Authenticated/private-repository onboarding and production OAuth/KMS UX also remain separate product work.
+
+## Automated fresh-install gates
+
+`.github/workflows/verify-quickstart.yml` repeats the fixture developer path in a blank temporary project:
+
+1. resolve the latest public `@nullsquare/agent-authority` version from npm;
+2. create a new empty npm project;
+3. install only that registry package;
+4. copy the quickstart file;
+5. confirm the optional AI SDK was not installed;
+6. run `node quickstart.mjs`.
+
+`.github/workflows/verify-live-quickstart.yml` repeats the real-provider path from another blank Node 20 project and requires exactly one live GitHub request before the unrelated repository is blocked.
+
+Both gates have passed against `@nullsquare/agent-authority@0.4.6`. They catch documentation/example drift against the actually published package. They do **not** substitute for timing a first-time external developer, so the roadmap's under-10-minute human adoption gate remains open until that evidence exists.

package/docs/release-v0.4.7.md

@@ -0,0 +1,38 @@
+# v0.4.7 connected execution
+
+v0.4.7 closes a concrete adoption gap between the task-first API and the existing credential broker/provider runtime.
+
+## What shipped
+
+- `task.execute(request)` executes through an `ExecutingAuthorityRuntime` while preserving the current Task Lease as the narrowest authority object.
+- connected deny/step-up outcomes use the same public error classes as `task.run()`.
+- successful connected execution returns sanitized provider output, receipt and execution evidence that can feed `task.authorityFrom()`.
+- `@nullsquare/agent-authority/runtime-env` exposes the existing local encrypted runtime composition for developer onboarding.
+- a sole active provider account can be resolved when requests omit `account_id`; multiple active accounts remain ambiguous and fail closed.
+- default disconnect can remove that sole connection without requiring the caller to know an auto-detected provider account ID.
+- the connected GitHub quickstart proves the local encrypted vault + credential broker + live provider path without copying credentials into task/model context.
+- the CLI version is now derived from `package.json` instead of a stale hard-coded constant.
+
+## Security boundary
+
+This release does not create a GitHub token, OAuth flow, GitHub App, KMS, or new identity format. Provider-side least privilege still comes from GitHub. Agent Authority adds a task boundary underneath that connected account authority.
+
+The local encrypted vault remains a trusted-local-host developer reference backend.
+
+## Release evidence
+
+The exact v0.4.7 candidate passed:
+
+- Node 20 and Node 22 test lanes;
+- coverage;
+- packed-package consumer smoke;
+- connected-execution packed consumer smoke;
+- Vercel AI SDK integration;
+- live GitHub read proof;
+- live evidence-derived GitHub mutation proof;
+- encrypted connected-GitHub onboarding proof;
+- CodeQL.
+
+After merge, the independent `Verify npm registry` workflow resolved version `0.4.7`, confirmed it was visible on npm, installed that exact registry artifact into a fresh Node 20 consumer, confirmed the optional AI SDK was absent, and successfully ran both the ordinary public package smoke and the connected-execution smoke.
+
+That registry proof is the basis for marking v0.4.7 published.

package/examples/live-github-derived-mutation.js

@@ -1,12 +1,10 @@
 import { CredentialBroker } from '../src/connections.js';
-import { AuthorityRuntime } from '../src/index.js';
 import {
   AuthorityApprovalRequiredError,
-  AuthorityDeniedError,
-  createTaskLeaseGuard
+  AuthorityDeniedError
 } from '../src/guard.js';
 import { createGitHubProviderAdapter } from '../src/providers/github.js';
-import { createTaskLease } from '../src/task-lease.js';
+import { createTask } from '../src/task.js';
 
 const repository = process.env.AA_VALIDATION_REPOSITORY || 'Null-Square/agent-authority';
 const marker = process.env.AA_VALIDATION_MARKER || 'agent-authority-live-fixture-v1';
@@ -19,69 +17,55 @@ if (!token) {
 const [owner, repo] = repository.split('/');
 if (!owner || !repo) throw new Error(`invalid repository: ${repository}`);
 
-const mission = {
-  version: '0.1',
+const task = createTask({
   mission_id: 'mission:live-derived-github-mutation',
-  principal: { id: 'user:validation' },
-  agent: { id: 'agent:github-actions-validation' },
+  principal: 'user:validation',
+  agent: 'agent:github-actions-validation',
+  request: 'Find the Agent Authority live validation fixture and leave one validation comment',
   objective: 'Discover the validation issue and comment only on that issue',
-  resources: [
-    {
-      service: 'github',
+  permissions: {
+    github: {
       allow: ['issue.list', 'issue.comment'],
       deny: ['issue.close', 'issue.delete', 'repo.write', 'repo.delete'],
       constraints: { repository: [repository] }
     }
-  ],
-  constraints: { expires_at: '2099-01-01T00:00:00Z' }
-};
-
-const lease = createTaskLease({
-  mission,
-  request: 'Find the Agent Authority live validation fixture and leave one validation comment',
-  roots: [
-    {
-      fact_id: 'fact:repository',
+  },
+  constraints: { expires_at: '2099-01-01T00:00:00Z' },
+  authority: {
+    repository: {
       kind: 'github.repository',
       value: repository,
       source: 'validation-task'
     },
-    {
-      fact_id: 'fact:fixture-marker',
+    fixtureMarker: {
       kind: 'github.issue.marker',
       value: marker,
       source: 'validation-task'
     }
-  ],
+  },
   bindings: [
     {
       service: 'github',
       action: 'issue.list',
-      context_field: 'repository',
-      fact_id: 'fact:repository'
+      field: 'repository',
+      authority: 'repository'
     },
     {
       service: 'github',
       action: 'issue.list',
-      context_field: 'fixture_marker',
-      fact_id: 'fact:fixture-marker'
+      field: 'fixture_marker',
+      authority: 'fixtureMarker'
     },
     {
       service: 'github',
       action: 'issue.comment',
-      context_field: 'repository',
-      fact_id: 'fact:repository'
-    },
-    {
-      service: 'github',
-      action: 'issue.comment',
-      context_field: 'issue_number',
-      fact_id: 'fact:discovered-issue-number'
+      field: 'repository',
+      authority: 'repository'
     }
   ]
 });
 
-const guard = createTaskLeaseGuard({ lease, runtime: new AuthorityRuntime() });
+const mission = task.mission;
 const broker = new CredentialBroker();
 broker.connect({
   principal_id: mission.principal.id,
@@ -95,7 +79,7 @@ const adapter = createGitHubProviderAdapter({ broker });
 const cleanupHeaders = {
   accept: 'application/vnd.github+json',
   authorization: `Bearer ${token}`,
-  'user-agent': 'agent-authority-derived-mutation-validation-cleanup',
+  'user-agent': 'agent-authority-task-first-derived-mutation-validation-cleanup',
   'x-github-api-version': '2022-11-28'
 };
 
@@ -119,7 +103,7 @@ function discoveryRequest() {
 
 async function discoverFixtureIssue() {
   const request = discoveryRequest();
-  return guard.run(request, async () => {
+  return task.run(request, async () => {
     providerReadCalls += 1;
     return adapter.execute({ mission, request });
   });
@@ -132,7 +116,7 @@ async function commentOnIssue(issueNumber, body) {
     context: { repository, issue_number: issueNumber, body }
   };
 
-  return guard.run(request, async () => {
+  return task.run(request, async () => {
     providerMutationCalls += 1;
     return adapter.execute({ mission, request });
   });
@@ -151,9 +135,10 @@ async function cleanupComment(commentId) {
 }
 
 try {
-  console.log(`Task root repository: ${repository}`);
-  console.log(`Task root fixture marker: ${marker}`);
-  console.log('1. Discover fixture through the reviewed GitHub provider adapter');
+  console.log('Task-first live workflow: discover one issue and comment only on that issue');
+  console.log(`Task root repository: ${task.authority('repository').value}`);
+  console.log(`Task root fixture marker: ${task.authority('fixtureMarker').value}`);
+  console.log('1. Discover fixture through task.run() and the reviewed GitHub provider adapter');
   const discovered = await discoverFixtureIssue();
 
   if (discovered.output.selected_issue_match_count !== 1) {
@@ -164,18 +149,21 @@ try {
   const extractor = adapter.authorityExtractor(discoveryRequest(), 'github.issue.number');
   if (!extractor) throw new Error('GitHub provider did not advertise the issue-number authority extractor');
 
-  const issueFact = lease.deriveFromEvidence({
-    fact_id: 'fact:discovered-issue-number',
+  const issueFact = task.authorityFrom(discovered, {
+    name: 'discoveredIssue',
     kind: 'github.issue.number',
-    from: ['fact:repository', 'fact:fixture-marker'],
-    receipt: discovered.receipt,
-    evidence: discovered.evidence,
-    output: discovered.output,
+    from: ['repository', 'fixtureMarker'],
     extractor
   });
-  console.log(`2. Evidence-verified authority -> issue #${issueFact.value}`);
+  task.bind({
+    service: 'github',
+    action: 'issue.comment',
+    field: 'issue_number',
+    authority: 'discoveredIssue'
+  });
+  console.log(`2. task.authorityFrom() -> issue #${issueFact.value}`);
 
-  const validationBody = `Agent Authority live evidence-derived authorization validation (${new Date().toISOString()}). Temporary comment; CI removes it after the proof.`;
+  const validationBody = `Agent Authority live task-first authorization validation (${new Date().toISOString()}). Temporary comment; CI removes it after the proof.`;
   const allowedMutation = await commentOnIssue(issueFact.value, validationBody);
   createdCommentId = allowedMutation.output.comment_id;
   console.log(`3. ALLOW -> real GitHub comment mutation executed (comment ${createdCommentId})`);
@@ -188,14 +176,19 @@ try {
     if (!(error instanceof AuthorityApprovalRequiredError) || error.code !== 'authority_delta_required') {
       throw error;
     }
+    const explanation = task.explain(error);
     console.log(`4. STEP-UP -> unrelated issue #${unrelatedIssue} blocked before provider mutation`);
+    console.log(`   ${explanation.summary}`);
+    if (explanation.established_authority?.value !== issueFact.value) {
+      throw new Error('task-first authority-delta explanation lost the established issue authority');
+    }
   }
 
   if (providerMutationCalls !== 1) {
     throw new Error(`expected exactly one task-side provider mutation before completion, got ${providerMutationCalls}`);
   }
 
-  lease.complete('live evidence-derived mutation validation complete');
+  task.complete('live task-first evidence-derived mutation validation complete');
   try {
     await commentOnIssue(issueFact.value, 'THIS MUST NOT RUN AFTER TASK COMPLETION');
     throw new Error('post-completion mutation unexpectedly executed');
@@ -213,8 +206,8 @@ try {
     throw new Error(`expected exactly one provider mutation after blocked attempts, got ${providerMutationCalls}`);
   }
 
-  console.log('PASS -> GitHub provider output became downstream authority only through execution evidence and a reviewed extractor');
-  console.log('PASS -> unrelated and post-completion mutations produced zero additional provider mutation calls');
+  console.log('PASS -> real GitHub provider output became task-first downstream authority through execution evidence and the reviewed extractor');
+  console.log('PASS -> unrelated and post-completion task-first calls produced zero additional provider mutations');
 } finally {
   if (createdCommentId) {
     await cleanupComment(createdCommentId);

package/examples/quickstart-github-connected.mjs

@@ -0,0 +1,77 @@
+import { createTask } from '@nullsquare/agent-authority/task';
+import { AuthorityApprovalRequiredError } from '@nullsquare/agent-authority/guard';
+import { createRuntimeEnvironment } from '@nullsquare/agent-authority/runtime-env';
+
+const repository = process.argv[2] || process.env.GITHUB_REPOSITORY || 'Null-Square/agent-authority';
+const unrelatedRepository = process.argv[3] || 'octocat/Hello-World';
+const env = createRuntimeEnvironment({ home: process.env.AGENT_AUTHORITY_HOME });
+
+const connection = env.broker.getConnection({
+  principal_id: env.config.principal_id,
+  service: 'github'
+});
+
+if (!connection) {
+  throw new Error(
+    'No unambiguous GitHub connection. Run: printf %s "$GITHUB_TOKEN" | agent-authority connect github --token-stdin'
+  );
+}
+
+const task = createTask({
+  principal: env.config.principal_id,
+  agent: 'agent:connected-quickstart',
+  request: `Inspect only ${repository} through the connected GitHub account`,
+  permissions: {
+    github: {
+      allow: ['repo.read'],
+      deny: ['repo.write', 'repo.delete'],
+      constraints: {}
+    }
+  },
+  authority: {
+    repository: { kind: 'github.repository', value: repository }
+  },
+  bindings: [
+    { service: 'github', action: 'repo.read', field: 'repository', authority: 'repository' }
+  ],
+  runtime: env.runtime
+});
+
+console.log(`Connected account -> ${connection.metadata?.login || connection.account_id}`);
+console.log('Credential location -> Agent Authority broker/vault (not task context)');
+console.log('Standing GitHub permission -> repo.read');
+console.log(`Task authority -> ${repository}`);
+
+const allowed = await task.execute({
+  service: 'github',
+  action: 'repo.read',
+  context: { repository }
+});
+
+console.log(`ALLOW -> connected GitHub returned ${allowed.output.body.full_name}`);
+
+try {
+  await task.execute({
+    service: 'github',
+    action: 'repo.read',
+    context: { repository: unrelatedRepository }
+  });
+  throw new Error('unrelated repository unexpectedly executed');
+} catch (error) {
+  if (!(error instanceof AuthorityApprovalRequiredError) || error.code !== 'authority_delta_required') {
+    throw error;
+  }
+  console.log(`STEP-UP -> ${task.explain(error).summary}`);
+}
+
+const visibleState = JSON.stringify({
+  mission: task.mission,
+  authorities: task.authorities(),
+  connection: env.broker.listConnections(env.config.principal_id),
+  allowed_output: allowed.output
+});
+if (/github_pat_|gh[pousr]_|Bearer\s/i.test(visibleState)) {
+  throw new Error('credential-like value leaked into public task state');
+}
+
+console.log('PASS -> connected credential stayed broker-internal and unrelated repository stayed outside task authority');