# Ecosystem Approvals And Trust Model

> **Status:** Draft stub
> **Owner:** `learning_ai_common_plat`
> **Reference inputs:** `learning_ai_smart_auth`, `learning_ai_auth_app`, `learning_ai_trails`, `learning_ai_mac_tooling`, `claw-cowork`
> **Purpose:** Define when the ecosystem should ask for approval, when it should not, and how trust posture affects automation.

---

## 1. Problem

The ecosystem wants fewer user steps, but it also includes:

- sensitive auth flows
- high-autonomy agent execution
- browser and desktop capture
- file manipulation
- scheduled automation
- device-risk signals

Without a shared trust model:

- users get too many prompts
- approvals are inconsistent
- products duplicate policy logic
- high-risk actions may bypass the wrong controls

---

## 2. Design Principle

Ask for approval only when risk or ambiguity justifies it.

That means:

- trusted identity + trusted device + low-risk action = no redundant prompt
- degraded device trust or destructive action = step-up approval
- every approval should create enough context to avoid repeated re-approval for the same safe run

---

## 3. Approval Inputs

The trust model should evaluate at least:

1. actor identity trust
2. device posture
3. action risk level
4. data sensitivity
5. execution mode
6. recent approvals
7. org policy

Signal sources:

- SmartAuth identity state
- Auth App approval device
- mac-tooling risk posture
- ActionTrail policy and replay history
- Cowork unattended/destructive-action policy

---

## 4. Suggested Trust Levels

### Identity trust

- `anonymous`
- `authenticated`
- `strong-auth`
- `step-up-verified`

### Device trust

- `unknown`
- `trusted`
- `degraded`
- `high-risk`

### Action risk

- `low`
- `moderate`
- `high`
- `destructive`

---

## 5. Example Policy Matrix

| Identity      | Device    | Action           | Outcome                              |
| ------------- | --------- | ---------------- | ------------------------------------ |
| strong-auth   | trusted   | low              | auto-allow                           |
| strong-auth   | trusted   | moderate         | allow with audit                     |
| strong-auth   | degraded  | moderate         | require step-up approval             |
| authenticated | trusted   | high             | require approval                     |
| any           | high-risk | high/destructive | block or require explicit escalation |

---

## 6. Shared Approval Record

```ts
type ApprovalRecord = {
  approvalId: string;
  userId: string;
  productId: string;
  sessionId?: string | null;
  runId?: string | null;
  actionType: string;
  actionRisk: 'low' | 'moderate' | 'high' | 'destructive';
  decision: 'approved' | 'denied' | 'expired';
  approvedAt?: string | null;
  deviceTrustAtDecision: string;
  identityTrustAtDecision: string;
  expiresAt?: string | null;
};
```

---

## 7. First Use Cases

1. Cowork destructive file action approval
2. Cowork unattended scheduled run policy
3. JarvisJr delegated action approval
4. FlowMonk high-autonomy execution approval
5. ecosystem auth step-up via Auth App

---

## 8. Key Open Decisions

1. How long should an approval remain reusable for a session or run?
2. Which actions should always require fresh approval regardless of trust?
3. How should degraded-device posture affect existing sessions in flight?
4. How should org admins override consumer defaults?
5. Which risk signals from mac-tooling are strong enough to block execution outright?

---

## 9. Acceptance Criteria

1. Low-risk repeated actions do not spam the user with prompts when trust is already high.
2. High-risk or destructive actions consistently require approval across products.
3. Auth App can approve an agent action using one canonical approval payload.
4. ActionTrail can render why an approval was required and what trust state triggered it.
5. Device-risk changes can alter approval behavior without changing product-local policy code.

---

## 10. Implementation Checklist

- [ ] finalize trust input model
- [ ] finalize risk taxonomy
- [ ] define approval reuse rules
- [ ] define fresh-approval-required action classes
- [ ] define degraded-device behavior
- [ ] define Auth App approval payload
- [ ] define ActionTrail approval rendering requirements

Commits:

- `eae3409` drafted the initial stub
- implementation commits: pending
