# Steward fleet audit report

Generated: 2026-07-26T06:08:46.699834+00:00

## Scope

- Agents analyzed: 30
- Tools analyzed: 34
- Delegation edges: 3
- Data discipline: Agent configuration metadata: grants, declared purpose, ownership, usage, and delegation. No agent payload data was analyzed.

## Executive summary

10 cited findings across 6 critical-risk agents. Fleet: 30 agent identities, 34 tools, 3 delegation edges.

**Top risks (composite score, reproducible every run):**

1. `support_bot` — Critical data-exfiltration path (64/100)
2. `report_bot` — Unused standing access: 2 direct grants (58/100)
3. `invoice_bot` — Critical fraud path: create vendor and approve payment (54/100)
4. `payroll_bot` — Critical ghost-employee fraud path (54/100)
5. `sales_bot` — AI-generalized toxic capability combination: Read CRM account context + Send email outside the company (54/100)

Findings map to 15 controls across 5 published frameworks (see coverage matrix; context, not a certification).
Certification review status: 30 pending.

## Peer-group outlier analytics

_1 agent(s) hold access unlike any peer. Indicative on a small fleet, not statistical: a legitimately unique role looks the same as a mistake._ (heuristic, not a finding; similarity threshold 0.3).

- `report_bot` — Holds 3 effective tools (2 high-impact: delete_records, export_data), but overlaps at most 25% with any peer (closest: bi_bot) — an access profile unlike the rest of the fleet, worth a look for over-grant.

## Control mapping

| Signal | Control language | Findings | Highest risk |
| --- | --- | ---: | --- |
| Delegation escalation | Delegated authority — confused-deputy control | 3 | critical |
| Orphaned agent | Accountability — named ownership | 1 | high |
| Over-privilege | Least privilege — periodic access certification | 1 | high |
| Segregation of duties | SOX ITGC — segregation of duties | 5 | critical |

## Control-framework coverage

Findings mapped to published control frameworks (versions cited). This matrix is auditor context — it is not a compliance certification.

| Framework | Control | Name | Findings | Signals |
| --- | --- | --- | ---: | --- |
| EU AI Act (Regulation (EU) 2024/1689) | Art. 14 | Human oversight | 5 | sod |
| ISO/IEC 27001:2022 | A.5.15 | Access control | 5 | sod |
| ISO/IEC 27001:2022 | A.5.16 | Identity management | 1 | orphan |
| ISO/IEC 27001:2022 | A.5.18 | Access rights | 6 | over_privilege, sod |
| ISO/IEC 27001:2022 | A.8.2 | Privileged access rights | 4 | escalation, over_privilege |
| NIST SP 800-53 Rev. 5 | AC-2 | Account Management | 1 | orphan |
| NIST SP 800-53 Rev. 5 | AC-5 | Separation of Duties | 8 | escalation, sod |
| NIST SP 800-53 Rev. 5 | AC-6 | Least Privilege | 3 | escalation |
| NIST SP 800-53 Rev. 5 | AC-6 / AC-6(1) | Least Privilege / Authorize Access to Security Functions | 1 | over_privilege |
| SOC 2 Trust Services Criteria (2017) | CC6.1 | Logical access security | 4 | escalation, over_privilege |
| SOC 2 Trust Services Criteria (2017) | CC6.2 | User registration and authorization | 1 | orphan |
| SOC 2 Trust Services Criteria (2017) | CC6.3 | Access modification and segregation of duties | 6 | over_privilege, sod |
| SOX ITGC | Access accountability | Accountable ownership of access | 1 | orphan |
| SOX ITGC | Least privilege | Least-privilege provisioning | 1 | over_privilege |
| SOX ITGC | SoD | Segregation of duties over financial processes | 5 | sod |

The governance process itself (signed audit ledger, certification queue) speaks to: EU AI Act (Regulation (EU) 2024/1689) Art. 12 (Record-keeping); NIST SP 800-53 Rev. 5 AU-2 (Event Logging); NIST SP 800-53 Rev. 5 AU-6 (Audit Record Review, Analysis, and Reporting); NIST SP 800-53 Rev. 5 AC-2 (Account Management (review)); ISO/IEC 27001:2022 A.8.15 (Logging).

## Optional model enrichment

**Status:** Recorded enrichment result

This analysis replays recorded enrichment metadata. Inspect the provenance note before treating it as a live model run.
- Provenance mode: cached live OpenAI gpt-oss-120b Bedrock result
- Disclosure: This zero-key cache was produced from a real OpenAI gpt-oss-120b Amazon Bedrock analysis of the committed synthetic fleet. Dashboard replay never calls Bedrock.
- Completion: 34/34 tools classified
- Finding narratives: ok (9 grounded narratives)
- Needed-access inference: ok (no coverage count recorded)
- Tool classification: ok (34/34 tools classified)
- Toxic-combination reasoning: ok (26/26 agents analyzed, 1 new cited finding)

## Grounded MCP threat context

These documented references provide context only. They are not additional Steward findings and do not replace the graph-entity evidence required for a finding to surface.

### MCP01 authentication and token-replay context (not a Steward finding)
- OWASP: [MCP01:2025: Token Mismanagement & Secret Exposure](https://owasp.org/www-project-mcp-top-10/2025/MCP01-2025-Token-Mismanagement-and-Secret-Exposure)
- Reference: [CVE-2026-32211 — Azure MCP Server missing authentication](https://nvd.nist.gov/vuln/detail/CVE-2026-32211) (NVD published 2 Apr 2026)
- Note: NVD records missing authentication for a critical Azure MCP Server function. Microsoft, the CNA, assigned CVSS 3.1 9.1 Critical; NVD's own score is 7.5 High. Token replay is a related MCP01 concern, but this CVE record specifically describes missing authentication—not token replay.

## Findings

### [CRITICAL · risk score 64/100] Critical data-exfiltration path

**Agent:** `support_bot`  
**Control:** Data protection — least privilege and controlled external egress
**Finding source:** Deterministic check — Rule-based detection from Steward's deterministic safety floor. The deterministic tier is covered by the labeled synthetic-fleet regression and precision gate.

SupportBot can read customer PII and directly send external email, creating a direct path for confidential customer data to be exfiltrated outside the organization, exposing the firm to regulatory violations, financial penalties, and reputational harm.

**Recommended action:** Revoke the direct read_customer_pii and send_external_email grants from SupportBot; implement least‑privilege controls, require mediated approval for external egress, and add monitoring/auditing of any PII access and outbound email activity.

**Evidence:**
- agent: `support_bot` — holds this effective-access combination
- tool: `read_customer_pii` — SupportBot has a direct grant of read_customer_pii.
- tool: `send_external_email` — SupportBot has a direct grant of send_external_email.

**Control-framework context (not a certification):**
- NIST SP 800-53 Rev. 5 AC-5 (Separation of Duties) — One agent identity holds both sides of a duty that the control requires to be separated.
- SOC 2 Trust Services Criteria (2017) CC6.3 (Access modification and segregation of duties) — Toxic capability combinations in one identity undermine segregation-of-duties objectives.
- ISO/IEC 27001:2022 A.5.15 (Access control) — Access rules should prevent a single identity from combining conflicting capabilities.
- ISO/IEC 27001:2022 A.5.18 (Access rights) — Provisioned rights should be reviewed so conflicting entitlements are not co-held.
- SOX ITGC SoD (Segregation of duties over financial processes) — An agent that can initiate and approve the same transaction defeats independent review.
- EU AI Act (Regulation (EU) 2024/1689) Art. 14 (Human oversight) — A toxic combination lets an AI agent complete a consequential action without an independent human checkpoint.

**Grounded MCP context (not graph evidence):**
- OWASP: [MCP03:2025: Tool Poisoning](https://owasp.org/www-project-mcp-top-10/2025/MCP03-2025%E2%80%93Tool-Poisoning) — A compromised or misleading tool can steer an agent toward unintended data handling or external actions.
- OWASP: [MCP04:2025: Software Supply Chain Attacks & Dependency Tampering](https://owasp.org/www-project-mcp-top-10/2025/MCP04-2025%E2%80%93Software-Supply-Chain-Attacks%26Dependency-Tampering) — A compromised MCP dependency can add covert external egress to an otherwise trusted workflow.
- Documented analogue: [Supabase MCP stored prompt-injection scenario](https://supabase.com/blog/defense-in-depth-mcp) (Documented 16 Sep 2025) — Supabase documented a scenario where stored instructions led an MCP-connected agent to read private database data and write it into an attacker-visible field. It illustrates this read-to-egress risk class; it is not evidence that this fleet uses Supabase.
- Documented analogue: [Malicious postmark-mcp package backdoor (v1.0.16)](https://postmarkapp.com/blog/information-regarding-malicious-postmark-mcp-package) (Postmark advisory, 25 Sep 2025) — Postmark reported that an impersonating npm package silently BCC'd email to an external server. It is an analogous tool-poisoning and supply-chain incident, not evidence that this fleet installed the package.

### [HIGH · risk score 58/100] Unused standing access: 2 direct grants

**Agent:** `report_bot`  
**Control:** Least privilege — access certification using granted versus used access
**Finding source:** Deterministic check — Rule-based detection from Steward's deterministic safety floor. The deterministic tier is covered by the labeled synthetic-fleet regression and precision gate.

ReportBot holds standing privileges to delete records and export data that are never exercised. If the agent were compromised or misused, an attacker could invoke these unused grants to irreversibly remove critical data or exfiltrate sensitive information, exposing the organization to data loss, regulatory non‑compliance, and reputational damage.

**Recommended action:** Revoke the unnecessary delete_records and export_data grants from ReportBot and re‑certify its access against the principle of least privilege. Implement periodic review of granted versus used permissions for all agents.

**Evidence:**
- agent: `report_bot` — usage log contains no invocation of these direct grants: delete_records, export_data
- tool: `delete_records` — ReportBot has a direct grant of delete_records.
- tool: `export_data` — ReportBot has a direct grant of export_data.

**Control-framework context (not a certification):**
- NIST SP 800-53 Rev. 5 AC-6 / AC-6(1) (Least Privilege / Authorize Access to Security Functions) — Standing grants with no observed use exceed the minimum access the agent's function requires.
- SOC 2 Trust Services Criteria (2017) CC6.1 (Logical access security) — Unused standing entitlements enlarge the logical-access attack surface without business need.
- SOC 2 Trust Services Criteria (2017) CC6.3 (Access modification and segregation of duties) — Granted-but-unused access should be removed through the access-modification process.
- ISO/IEC 27001:2022 A.8.2 (Privileged access rights) — High-risk unused entitlements are privileged rights that should be restricted and reviewed.
- ISO/IEC 27001:2022 A.5.18 (Access rights) — Access rights should be adjusted when observed use does not support the grant.
- SOX ITGC Least privilege (Least-privilege provisioning) — Unused financially-relevant entitlements weaken ITGC access assertions.

### [CRITICAL · risk score 54/100] Critical fraud path: create vendor and approve payment

**Agent:** `invoice_bot`  
**Control:** SOX ITGC — segregation of duties (vendor creation versus payment approval)
**Finding source:** Deterministic check — Rule-based detection from Steward's deterministic safety floor. The deterministic tier is covered by the labeled synthetic-fleet regression and precision gate.

InvoiceBot possesses both the create_vendor and approve_payment tool grants, giving a single automated agent the ability to add new vendors and subsequently authorize payments to those vendors. This concentration of authority creates a direct fraud pathway that could be exploited to generate fictitious vendors and approve unauthorized disbursements, potentially resulting in material financial loss and SOX compliance violations across the entire accounts‑payable function.

**Recommended action:** Implement segregation of duties by revoking either the create_vendor or approve_payment grant from InvoiceBot, enforce dual‑approval controls for vendor creation and payment authorization, and add continuous monitoring to detect any instance where a single entity performs both actions.

**Evidence:**
- agent: `invoice_bot` — holds this effective-access combination
- tool: `approve_payment` — InvoiceBot has a direct grant of approve_payment.
- tool: `create_vendor` — InvoiceBot has a direct grant of create_vendor.

**Control-framework context (not a certification):**
- NIST SP 800-53 Rev. 5 AC-5 (Separation of Duties) — One agent identity holds both sides of a duty that the control requires to be separated.
- SOC 2 Trust Services Criteria (2017) CC6.3 (Access modification and segregation of duties) — Toxic capability combinations in one identity undermine segregation-of-duties objectives.
- ISO/IEC 27001:2022 A.5.15 (Access control) — Access rules should prevent a single identity from combining conflicting capabilities.
- ISO/IEC 27001:2022 A.5.18 (Access rights) — Provisioned rights should be reviewed so conflicting entitlements are not co-held.
- SOX ITGC SoD (Segregation of duties over financial processes) — An agent that can initiate and approve the same transaction defeats independent review.
- EU AI Act (Regulation (EU) 2024/1689) Art. 14 (Human oversight) — A toxic combination lets an AI agent complete a consequential action without an independent human checkpoint.

### [CRITICAL · risk score 54/100] Critical ghost-employee fraud path

**Agent:** `payroll_bot`  
**Control:** SOX ITGC — segregation of duties (employee setup versus payroll execution)
**Finding source:** Deterministic check — Rule-based detection from Steward's deterministic safety floor. The deterministic tier is covered by the labeled synthetic-fleet regression and precision gate.

PayrollBot holds direct authority to both add_employee (employee creation) and run_payroll (payroll execution). This conflation of employee setup and payroll processing creates a critical segregation‑of‑duties violation, enabling a malicious or compromised bot to create ghost employees and issue unauthorized payroll payments, potentially resulting in financial loss, regulatory non‑compliance, and reputational harm across the entire payroll function.

**Recommended action:** Re‑engineer the permission model to enforce segregation of duties: remove the direct add_employee grant from PayrollBot, require an independent approval workflow for employee creation, and limit payroll execution to a separate, controlled role. Implement least‑privilege access, periodic access reviews, and monitoring of employee‑creation and payroll‑run activities.

**Evidence:**
- agent: `payroll_bot` — holds this effective-access combination
- tool: `add_employee` — PayrollBot has a direct grant of add_employee.
- tool: `run_payroll` — PayrollBot has a direct grant of run_payroll.

**Control-framework context (not a certification):**
- NIST SP 800-53 Rev. 5 AC-5 (Separation of Duties) — One agent identity holds both sides of a duty that the control requires to be separated.
- SOC 2 Trust Services Criteria (2017) CC6.3 (Access modification and segregation of duties) — Toxic capability combinations in one identity undermine segregation-of-duties objectives.
- ISO/IEC 27001:2022 A.5.15 (Access control) — Access rules should prevent a single identity from combining conflicting capabilities.
- ISO/IEC 27001:2022 A.5.18 (Access rights) — Provisioned rights should be reviewed so conflicting entitlements are not co-held.
- SOX ITGC SoD (Segregation of duties over financial processes) — An agent that can initiate and approve the same transaction defeats independent review.
- EU AI Act (Regulation (EU) 2024/1689) Art. 14 (Human oversight) — A toxic combination lets an AI agent complete a consequential action without an independent human checkpoint.

### [HIGH · risk score 54/100] AI-generalized toxic capability combination: Read CRM account context + Send email outside the company

**Agent:** `sales_bot`  
**Control:** Identity governance — Model-identified segregation-of-duties candidate
**Finding source:** LLM-generalized — The configured model proposed this additional combination; Steward verified its graph citations before showing it. It is evaluated separately from the deterministic golden-set gate.

The SalesBot agent can both read CRM account context and send email outside the company, creating a direct path to expose customer information to external recipients. This combination can lead to unauthorized data disclosure, regulatory non‑compliance, reputational damage, and potential financial loss.

**Recommended action:** Separate the read_crm and send_external_email permissions, enforce a dual‑approval workflow for any external email that includes CRM data, and implement continuous monitoring and audit of combined usage.

**Evidence:**
- agent: `sales_bot` — holds the cited effective-access combination.
- tool: `read_crm` — SalesBot has a direct grant of read_crm.
- tool: `send_external_email` — SalesBot has a direct grant of send_external_email.

**Control-framework context (not a certification):**
- NIST SP 800-53 Rev. 5 AC-5 (Separation of Duties) — One agent identity holds both sides of a duty that the control requires to be separated.
- SOC 2 Trust Services Criteria (2017) CC6.3 (Access modification and segregation of duties) — Toxic capability combinations in one identity undermine segregation-of-duties objectives.
- ISO/IEC 27001:2022 A.5.15 (Access control) — Access rules should prevent a single identity from combining conflicting capabilities.
- ISO/IEC 27001:2022 A.5.18 (Access rights) — Provisioned rights should be reviewed so conflicting entitlements are not co-held.
- SOX ITGC SoD (Segregation of duties over financial processes) — An agent that can initiate and approve the same transaction defeats independent review.
- EU AI Act (Regulation (EU) 2024/1689) Art. 14 (Human oversight) — A toxic combination lets an AI agent complete a consequential action without an independent human checkpoint.

**Grounded MCP context (not graph evidence):**
- OWASP: [MCP03:2025: Tool Poisoning](https://owasp.org/www-project-mcp-top-10/2025/MCP03-2025%E2%80%93Tool-Poisoning) — A compromised or misleading tool can steer an agent toward unintended data handling or external actions.
- OWASP: [MCP04:2025: Software Supply Chain Attacks & Dependency Tampering](https://owasp.org/www-project-mcp-top-10/2025/MCP04-2025%E2%80%93Software-Supply-Chain-Attacks%26Dependency-Tampering) — A compromised MCP dependency can add covert external egress to an otherwise trusted workflow.
- Documented analogue: [Supabase MCP stored prompt-injection scenario](https://supabase.com/blog/defense-in-depth-mcp) (Documented 16 Sep 2025) — Supabase documented a scenario where stored instructions led an MCP-connected agent to read private database data and write it into an attacker-visible field. It illustrates this read-to-egress risk class; it is not evidence that this fleet uses Supabase.
- Documented analogue: [Malicious postmark-mcp package backdoor (v1.0.16)](https://postmarkapp.com/blog/information-regarding-malicious-postmark-mcp-package) (Postmark advisory, 25 Sep 2025) — Postmark reported that an impersonating npm package silently BCC'd email to an external server. It is an analogous tool-poisoning and supply-chain incident, not evidence that this fleet installed the package.

### [CRITICAL · risk score 49/100] Delegated payment-approval blast radius

**Agent:** `chief_of_staff_bot`  
**Control:** Identity governance — effective access review and least privilege
**Finding source:** Deterministic check — Rule-based detection from Steward's deterministic safety floor. The deterministic tier is covered by the labeled synthetic-fleet regression and precision gate.

Through the delegation edge, ChiefOfStaffBot can reach the finance_bot, which directly holds the approve_payment tool. Consequently, any user or process that can invoke ChiefOfStaffBot inherits the ability to trigger payment approvals via finance_bot. The practical blast radius therefore extends to all payment transactions that finance_bot is authorized to approve, creating a critical risk of unauthorized or fraudulent payments if the delegation is not tightly controlled.

**Recommended action:** Conduct an immediate access review of the delegation relationship between ChiefOfStaffBot and finance_bot. Restrict delegation to only verified, least‑privilege identities, enforce multi‑factor approval for payment actions, and implement monitoring/auditing of all approve_payment invocations originating from ChiefOfStaffBot.

**Evidence:**
- agent: `chief_of_staff_bot` — reaches approve_payment only through delegation to finance_bot
- delegation_edge: `chief_of_staff_bot->finance_bot` — chief_of_staff_bot can delegate to finance_bot.
- agent: `finance_bot` — finance_bot is the direct grant holder reached through chief_of_staff_bot -> finance_bot.
- tool: `approve_payment` — ChiefOfStaffBot effectively reaches approve_payment through chief_of_staff_bot -> finance_bot.

**Control-framework context (not a certification):**
- NIST SP 800-53 Rev. 5 AC-6 (Least Privilege) — Delegation extends the agent's effective privilege beyond its direct provisioning.
- NIST SP 800-53 Rev. 5 AC-5 (Separation of Duties) — Authority reachable through delegation recombines duties the direct grants kept separate.
- SOC 2 Trust Services Criteria (2017) CC6.1 (Logical access security) — Effective access through delegation is logical access and must be evaluated as such.
- ISO/IEC 27001:2022 A.8.2 (Privileged access rights) — A privileged capability reachable only through delegation is still a privileged right of that identity.

### [CRITICAL · risk score 49/100] Delegated payment-approval blast radius

**Agent:** `exec_briefing_bot`  
**Control:** Identity governance — effective access review and least privilege
**Finding source:** Deterministic check — Rule-based detection from Steward's deterministic safety floor. The deterministic tier is covered by the labeled synthetic-fleet regression and precision gate.

Compromise of ExecBriefingBot grants indirect access to the approve_payment tool via the delegation chain (ExecBriefingBot → chief_of_staff_bot → finance_bot). An attacker who gains control of ExecBriefingBot could approve payments without direct authorization, exposing the organization to unauthorized disbursements and potential financial loss.

**Recommended action:** Restrict delegation paths so that ExecBriefingBot cannot reach payment‑approval capabilities, enforce least‑privilege principles on delegation edges, conduct an immediate access review of all delegated relationships, and implement monitoring/alerting for any use of approve_payment originating from indirect agents.

**Evidence:**
- agent: `exec_briefing_bot` — reaches approve_payment only through delegation to finance_bot
- delegation_edge: `exec_briefing_bot->chief_of_staff_bot` — exec_briefing_bot can delegate to chief_of_staff_bot.
- delegation_edge: `chief_of_staff_bot->finance_bot` — chief_of_staff_bot can delegate to finance_bot.
- agent: `finance_bot` — finance_bot is the direct grant holder reached through exec_briefing_bot -> chief_of_staff_bot -> finance_bot.
- tool: `approve_payment` — ExecBriefingBot effectively reaches approve_payment through exec_briefing_bot -> chief_of_staff_bot -> finance_bot.

**Control-framework context (not a certification):**
- NIST SP 800-53 Rev. 5 AC-6 (Least Privilege) — Delegation extends the agent's effective privilege beyond its direct provisioning.
- NIST SP 800-53 Rev. 5 AC-5 (Separation of Duties) — Authority reachable through delegation recombines duties the direct grants kept separate.
- SOC 2 Trust Services Criteria (2017) CC6.1 (Logical access security) — Effective access through delegation is logical access and must be evaluated as such.
- ISO/IEC 27001:2022 A.8.2 (Privileged access rights) — A privileged capability reachable only through delegation is still a privileged right of that identity.

### [CRITICAL · risk score 49/100] Delegated payment-approval blast radius

**Agent:** `summary_bot`  
**Control:** Identity governance — effective access review and least privilege
**Finding source:** Deterministic check — Rule-based detection from Steward's deterministic safety floor. The deterministic tier is covered by the labeled synthetic-fleet regression and precision gate.

This agent does not hold payment approval directly, but it can reach an agent that does through delegation. Its effective access therefore includes authority to authorize disbursements, creating a confused-deputy path.

**Recommended action:** Remove or constrain the delegation link to the payment-approving agent. If delegation is necessary, expose a narrowly scoped workflow action rather than the delegate's general approval authority.

**Evidence:**
- agent: `summary_bot` — reaches approve_payment only through delegation to finance_bot
- delegation_edge: `summary_bot->finance_bot` — summary_bot can delegate to finance_bot.
- agent: `finance_bot` — finance_bot is the direct grant holder reached through summary_bot -> finance_bot.
- tool: `approve_payment` — SummaryBot effectively reaches approve_payment through summary_bot -> finance_bot.

**Control-framework context (not a certification):**
- NIST SP 800-53 Rev. 5 AC-6 (Least Privilege) — Delegation extends the agent's effective privilege beyond its direct provisioning.
- NIST SP 800-53 Rev. 5 AC-5 (Separation of Duties) — Authority reachable through delegation recombines duties the direct grants kept separate.
- SOC 2 Trust Services Criteria (2017) CC6.1 (Logical access security) — Effective access through delegation is logical access and must be evaluated as such.
- ISO/IEC 27001:2022 A.8.2 (Privileged access rights) — A privileged capability reachable only through delegation is still a privileged right of that identity.

**Grounded MCP context (not graph evidence):**
- OWASP: [MCP02:2025: Privilege Escalation via Scope Creep](https://owasp.org/www-project-mcp-top-10/2025/MCP02-2025%E2%80%93Privilege-Escalation-via-Scope-Creep) — Delegated authority can turn a narrowly scoped agent into a higher-impact actor through effective access.
- Documented analogue: [Invariant Labs GitHub MCP toxic agent flow](https://invariantlabs.ai/blog/mcp-github-vulnerability) (26 May 2025) — Invariant demonstrated an untrusted GitHub issue coercing an MCP-connected agent to move private repository data into a public pull request. It illustrates how composed authority paths can exceed an agent's apparent role.

### [HIGH · risk score 44/100] Self-granting privilege path

**Agent:** `access_bot`  
**Control:** Identity governance — segregation of duties (access request versus access grant)
**Finding source:** Deterministic check — Rule-based detection from Steward's deterministic safety floor. The deterministic tier is covered by the labeled synthetic-fleet regression and precision gate.

AccessBot possesses both the request_access and grant_access capabilities, creating a self‑granting privilege path. This enables the agent to request and immediately approve access to applications without independent review, allowing unauthorized privilege escalation across the organization’s systems. The blast radius includes potential exposure of sensitive data, violation of compliance requirements, and the ability for an attacker who compromises the bot to obtain unrestricted access to any application the bot can request.

**Recommended action:** Segregate duties by removing the direct grant of the grant_access tool from AccessBot. Implement an approval workflow that requires a separate, privileged role to approve access requests. Apply least‑privilege principles to the agent, enforce monitoring of any grant actions, and conduct periodic reviews of agent permissions.

**Evidence:**
- agent: `access_bot` — holds this effective-access combination
- tool: `grant_access` — AccessBot has a direct grant of grant_access.
- tool: `request_access` — AccessBot has a direct grant of request_access.

**Control-framework context (not a certification):**
- NIST SP 800-53 Rev. 5 AC-5 (Separation of Duties) — One agent identity holds both sides of a duty that the control requires to be separated.
- SOC 2 Trust Services Criteria (2017) CC6.3 (Access modification and segregation of duties) — Toxic capability combinations in one identity undermine segregation-of-duties objectives.
- ISO/IEC 27001:2022 A.5.15 (Access control) — Access rules should prevent a single identity from combining conflicting capabilities.
- ISO/IEC 27001:2022 A.5.18 (Access rights) — Provisioned rights should be reviewed so conflicting entitlements are not co-held.
- SOX ITGC SoD (Segregation of duties over financial processes) — An agent that can initiate and approve the same transaction defeats independent review.
- EU AI Act (Regulation (EU) 2024/1689) Art. 14 (Human oversight) — A toxic combination lets an AI agent complete a consequential action without an independent human checkpoint.

### [HIGH · risk score 30/100] Ownerless agent has no accountable reviewer

**Agent:** `legacy_bot`  
**Control:** Accountability — named owner required for agent access certification
**Finding source:** Deterministic check — Rule-based detection from Steward's deterministic safety floor. The deterministic tier is covered by the labeled synthetic-fleet regression and precision gate.

The LegacyBot agent lacks an assigned owner, so no individual is accountable for its access rights or activity. This creates a compliance gap (missing reviewer for access certification) and increases the risk of undetected misuse or unauthorized data exposure through the agent's operations.

**Recommended action:** Assign a named owner in the fleet inventory, update the agent's governance record, and include the agent in the regular access certification process to ensure accountability.

**Evidence:**
- agent: `legacy_bot` — owner is null in the fleet inventory

**Control-framework context (not a certification):**
- NIST SP 800-53 Rev. 5 AC-2 (Account Management) — An agent identity with no accountable owner cannot be certified, reviewed, or deprovisioned on schedule.
- SOC 2 Trust Services Criteria (2017) CC6.2 (User registration and authorization) — Identities must be traceable to an accountable party throughout their lifecycle.
- ISO/IEC 27001:2022 A.5.16 (Identity management) — The full life cycle of an identity — including this non-human one — requires a responsible owner.
- SOX ITGC Access accountability (Accountable ownership of access) — Ownerless identities break the accountability chain ITGC access reviews depend on.

## Certification queue (ranked by composite risk score)

- `support_bot` (SupportBot) — risk: **critical**, top score: 64/100, review: pending
- `report_bot` (ReportBot) — risk: **high**, top score: 58/100, review: pending
- `invoice_bot` (InvoiceBot) — risk: **critical**, top score: 54/100, review: pending
- `payroll_bot` (PayrollBot) — risk: **critical**, top score: 54/100, review: pending
- `sales_bot` (SalesBot) — risk: **high**, top score: 54/100, review: pending
- `chief_of_staff_bot` (ChiefOfStaffBot) — risk: **critical**, top score: 49/100, review: pending
- `exec_briefing_bot` (ExecBriefingBot) — risk: **critical**, top score: 49/100, review: pending
- `summary_bot` (SummaryBot) — risk: **critical**, top score: 49/100, review: pending
- `access_bot` (AccessBot) — risk: **high**, top score: 44/100, review: pending
- `legacy_bot` (LegacyBot) — risk: **high**, top score: 30/100, review: pending
- `bi_bot` (BusinessIntelligenceBot) — risk: **clear**, review: pending
- `compliance_bot` (ComplianceBot) — risk: **clear**, review: pending
- `contract_bot` (ContractBot) — risk: **clear**, review: pending
- `customer_success_bot` (CustomerSuccessBot) — risk: **clear**, review: pending
- `data_quality_bot` (DataQualityBot) — risk: **clear**, review: pending
- `engineering_bot` (EngineeringBot) — risk: **clear**, review: pending
- `facilities_bot` (FacilitiesBot) — risk: **clear**, review: pending
- `finance_bot` (FinanceBot) — risk: **clear**, review: pending
- `inventory_bot` (InventoryBot) — risk: **clear**, review: pending
- `knowledge_bot` (KnowledgeBot) — risk: **clear**, review: pending
- `marketing_bot` (MarketingBot) — risk: **clear**, review: pending
- `monitoring_bot` (MonitoringBot) — risk: **clear**, review: pending
- `onboarding_bot` (OnboardingBot) — risk: **clear**, review: pending
- `procurement_bot` (ProcurementBot) — risk: **clear**, review: pending
- `recruiting_bot` (RecruitingBot) — risk: **clear**, review: pending
- `research_bot` (ResearchBot) — risk: **clear**, review: pending
- `sales_assist_bot` (SalesAssistBot) — risk: **clear**, review: pending
- `scheduler_bot` (SchedulerBot) — risk: **clear**, review: pending
- `secops_bot` (SecOpsBot) — risk: **clear**, review: pending
- `travel_bot` (TravelBot) — risk: **clear**, review: pending