# AGENT AUTHORITY & SECURITY BOUNDARY PACK: Procurement Agent Evidence labels: **C** = Confirmed, **HL** = Highly Likely, **P** = Plausible, **U** = Unknown. Every control is **REQUIRED CONTROL, IMPLEMENTATION UNVERIFIED** unless you tell me it already exists. --- ## 1. SECURITY BOUNDARY SUMMARY - **C:** The agent reads untrusted content (web, email, attachments, portals), reads confidential data (CRM, document repository), and can send outbound messages to suppliers. - **Core structural risk (HL):** This is a "read untrusted + read confidential + communicate externally" loop. One injected instruction in a supplier PDF could cause the agent to email confidential data to an attacker-controlled address, or to a real supplier who should not see it. This is the highest-priority boundary. - **C:** The agent must not place orders, accept contracts, change bank or payment details, transfer money, or make final supplier selections. These must be unreachable by the agent, not merely prohibited by prompt. - **U:** Several things are not stated: - Whether the agent acts under a per-user or shared service identity. - What "routine" means for follow-ups. - Whether orchestrators or sub-agents exist. - Whether the CRM, portals, and email support scoped or read-only roles. - What approval tooling exists. - What audit logging exists. - **Design stance:** Reasoning is not authorization. Every R2+ action passes a deterministic gateway before execution. --- ## 2. PRINCIPAL & AUTHORITY MAP | Principal | Identity | Authorized by / source | Delegated scope | Credential | Trust | Expiry | |---|---|---|---|---|---|---| | Procurement staff member | Named employee (U: SSO/IdP unknown) | Organization role | Initiates tasks; approves R3 | IdP session | High (authenticated) | Session | | Organization / operator | Company | Corporate policy | Defines max authority and policy | n/a | Highest | Policy version | | Procurement agent | Dedicated non-human identity (REQUIRED CONTROL) | Operator + task-scoped delegation from staff member | Research, read, draft, log, limited send | None held; brokered | Medium (model can be manipulated) | Per task/session | | Orchestrator / sub-agents | **U: not described** | Must derive from agent | Never more than the agent | Brokered | Medium | Per task | | Tool gateway / credential broker | Platform component | Operator | Enforce policy, mint tokens | Holds secrets | Trusted (deterministic) | n/a | | Email, CRM, portals, doc store | Systems of record | Operator | Accept only gateway-issued scoped tokens | Short-lived scoped tokens | Internal systems are trusted, but their **content** is not | Token TTL | | Suppliers, websites, senders | External | None | None. Data only. | None | Untrusted | n/a | **Ambiguous principal (flag):** If the agent runs under one shared service account, the audit trail cannot say which human it acted for. This is **AMBIGUOUS PRINCIPAL**. Required: every action carries `(human_principal, agent_id, task_id)`. --- ## 3. DELEGATION CHAIN | Hop | Purpose | Resource / action scope | Time scope | Propagated identity | Prohibited escalation | Audit | |---|---|---|---|---|---|---| | Staff → Agent | A specific procurement task (e.g. "evaluate suppliers for X") | Only that task's suppliers, folders, and CRM records | Task/session | Staff ID + task ID | Agent cannot broaden to other users' records or other tasks | Task creation event | | Agent → Tool gateway | One tool call | Per-tool allowlist (section 9) | Single call | Agent ID + task ID + staff ID | Cannot select credentials or endpoints directly | Policy decision event | | Gateway → Broker → System | Execute approved call | Narrowest token for that call | Minutes | Scoped token bound to task | No token reuse across tasks or tools | Token mint and use | | Agent → Sub-agent (if any) | Subtask | Subset of agent scope | Subtask | Same chain, hop count recorded | Cannot exceed parent; cannot receive approvals | Handoff event | **Detected risks:** - **CONFUSED-DEPUTY RISK:** The agent holds broad mailbox/CRM reach, but external senders steer it through content. External parties would act through the agent's authority. - **SCOPE LOSS:** If the task scope is not bound into the token, the agent could read the whole mailbox or CRM rather than just the task's records. - **UNTRACEABLE DELEGATION:** Present if a shared service account is used (U). --- ## 4. DATA TRUST & ACCESS MAP | Source | Class | Read | Write | Purpose / scope | Retention | Cross-tenant/user risk | Injection exposure | |---|---|---|---|---|---|---|---| | Public web | EXTERNAL / UNTRUSTED | Agent via sandboxed fetcher | None | Supplier research | Summaries only, with source tag | Low | **High** | | Email (inbound) | EXTERNAL / UNTRUSTED; sensitive | Agent, scoped to procurement threads/labels | Drafts only (send via gateway) | Supplier correspondence | Threads stay in mailbox; no copying into memory | **High** if the mailbox is shared | **High** | | Attachments / supplier docs | EXTERNAL / UNTRUSTED | Agent, parsed in sandbox | None | Quotation comparison | Extracted fields, not raw docs | Medium | **High** (hidden text, metadata) | | Supplier portals | EXTERNAL content; authenticated session | Agent, read-only role (U: availability) | None | Status, quotes, catalog | Extracted fields | Medium | **High** | | CRM | AUTHORIZED INTERNAL; SENSITIVE | Agent, scoped to supplier records for the task | Restricted fields only (section 9) | System of record | Per CRM policy (U) | **High** if the agent can query across accounts | **Medium–High** (free-text fields hold supplier-origin text) | | Internal document repository | AUTHORIZED INTERNAL; SENSITIVE | Agent, procurement collections only | Agent workspace only | Policies, past quotes | Per repo policy (U) | Medium | Medium (uploaded supplier docs) | | Credentials | SECRET | **Broker only** | Broker only | n/a | n/a | n/a | n/a | **Rule:** Instructions found in any of these sources are DATA. They cannot grant authority, change recipients, alter policy, or add tools. **Data-classification caveat (U):** You said supplier and company information is confidential, but no formal classification scheme was supplied. I treat all CRM and repository content as SENSITIVE by default. --- ## 5. ACTION INVENTORY | # | Action | Tool / resource | Side effect | Reversible? | Sensitivity | External visibility | |---|---|---|---|---|---|---| | A1 | Web search/fetch | Sandboxed fetcher | None (but URL egress) | n/a | Low | Request visible to the site | | A2 | Read email | Mail (read scope) | None | n/a | High | None | | A3 | Read portal | Portal (read-only) | None (U: some portals log views) | n/a | Medium–High | Minimal | | A4 | Read CRM | CRM read | None | n/a | High | None | | A5 | Read doc repo | Repo read | None | n/a | High | None | | A6 | Parse attachments / compare quotes | Sandboxed parser (+ calculation if any) | None | n/a | Medium | None | | A7 | Write CRM, non-financial notes/fields | CRM write | Record change | Yes (versioned) | High | Internal | | A8 | Write CRM, payment/bank/contact-of-record fields | CRM write | Could redirect payments | Hard | Critical | Internal, with financial consequence | | A9 | Draft supplier message | Mail drafts | None until sent | Yes | Medium | None | | A10 | Send routine follow-up | Mail send | Message delivered | **No** | Medium | **External** | | A11 | Send message containing price, terms, acceptance, or commitment | Mail send | Possibly binding | No | High | External | | A12 | Prepare recommendation | Internal doc | None | Yes | Medium | Internal | | A13 | Final supplier selection | n/a | Binding business decision | No | High | Business consequence | | A14 | Place PO / accept contract / transfer money / change payment details | n/a | Financial/legal | No | Critical | External | | A15 | Change account permissions (portal/CRM/mail) | n/a | Security | Hard | Critical | n/a | --- ## 6. ACTION RISK MATRIX | Action | Class | Rationale | |---|---|---| | A1–A6 | **R0** (A1: R0 with egress controls) | No mutation. Exfiltration via URLs and attachments is controlled at the network layer, not by the class. | | A7 | **R1** | Versioned, internal, rollback possible. Scope is limited to non-financial fields. | | A8 | **R4** | Payment-detail change is explicitly out of agent authority. Classified R4 because of your constraint. | | A9 | **R1** | Draft only. | | A10 | **R2**, conditionally. **R3** if conditions fail | The message is irreversible and externally visible. It is R2 only for template-bound, allowlisted-recipient, no-attachment, no-commercial-content messages. | | A11 | **R3** | Can create commercial expectations or binding language. | | A12 | **R1** | Advisory only. | | A13 | **R4 / HUMAN-ONLY** | Explicit constraint. | | A14 | **R4 / HUMAN-ONLY** | Explicit constraint. | | A15 | **R3 → DENY** | No supplied need. Approval is required in principle, but the agent has no reason to request it. | --- ## 7. AUTHORIZATION POLICY MATRIX | Action | Principal / scope required | Preconditions | Autonomous? | Human approval? | Secondary check | Prohibited conditions | State | |---|---|---|---|---|---|---|---| | A1 Web | Agent / task | Egress allowlist or sanitizing proxy | Yes | No | URL/param inspection | Authenticated sessions; URLs containing internal data; non-HTTP(S) | **ALLOW WITH CONSTRAINTS** | | A2 Email read | Agent / task + labeled threads | Task bound | Yes | No | n/a | Threads outside procurement scope | **ALLOW WITH CONSTRAINTS** | | A3 Portal read | Agent / read-only role | Portal role is read-only (U) | Yes | No | n/a | Any form submit, button click that mutates | **ALLOW WITH CONSTRAINTS** | | A4 CRM read | Agent / task suppliers | Record-level scope (U) | Yes | No | n/a | Cross-account queries, bulk export | **ALLOW WITH CONSTRAINTS** | | A5 Repo read | Agent / procurement collections | Collection ACL | Yes | No | n/a | Other departments' collections | **ALLOW WITH CONSTRAINTS** | | A6 Parse/compare | Agent / sandbox | Sandbox only | Yes | No | Output schema validation | Execution of document macros/active content | **ALLOW WITH CONSTRAINTS** | | A7 CRM write (non-financial) | Agent / allowlisted fields | Provenance tag (source, task, timestamp); schema validation | Yes | No | Diff logged | Fields outside allowlist; overwrite of human-edited values without flag | **ALLOW WITH CONSTRAINTS** | | A8 CRM payment/bank fields | None | n/a | **No** | Human-only | n/a | Any agent path | **HUMAN-ONLY** | | A9 Draft | Agent | Task bound | Yes | No | n/a | None beyond content policy | **ALLOW** | | A10 Routine send | Agent / allowlisted recipients | Recipient is an existing supplier contact of record, matched to the task. Template class is approved. No attachments. Passes commitment-language and DLP scan. Within rate limit | Yes (if all pass) | No | Deterministic content scan | New/changed recipient; recipient derived from inbound content; any internal confidential data; any price/term/commitment | **ALLOW WITH CONSTRAINTS** (**UNKNOWN: POLICY REQUIRED** for the definition of "routine") | | A11 Commercial/binding message | Staff approver | Draft preview | No | Yes | Content re-check on send | Edits after approval | **REQUIRE APPROVAL** | | A12 Recommendation | Agent | Marked "advisory, not a selection" | Yes | n/a (staff reviews) | n/a | Language implying selection or award | **ALLOW** | | A13 Final selection | Staff with authority | n/a | No | Human decision | n/a | Any agent action | **HUMAN-ONLY** | | A14 PO/contract/transfer | Authorized humans via separate systems | n/a | No | Human | n/a | No agent credentials exist | **HUMAN-ONLY** | | A15 Permissions | None | n/a | No | n/a | n/a | n/a | **DENY** | --- ## 8. POLICY ENFORCEMENT ARCHITECTURE All items are **REQUIRED CONTROL, IMPLEMENTATION UNVERIFIED**. | Policy | Enforcement point | Fail-closed behavior | Bypass risk | Audit event | |---|---|---|---|---| | Per-tool operation/parameter allowlist | **Tool gateway** | Unknown operation → deny | Direct system access outside the gateway (must be network-blocked) | `tool.decision` | | Task-scoped, short-lived tokens | **Credential broker** | Mint failure → no call | Token reuse across tasks | `token.mint/use` | | No order/contract/payment/permission capability | **Identity provider + system roles** (the agent identity has no such roles) | Missing role → 403 | Over-broad service account roles | `authz.denied` | | CRM field allowlist; payment fields unwritable | **Database/CRM policy** (field-level permissions) | Write to non-allowlisted field rejected | CRM may not support field-level control (U) | `crm.write.rejected` | | Recipient allowlist, no attachments, commitment scan, rate limit | **Mail gateway (outbound)** | Scan failure → hold for approval, not send | Alternate send paths (API, portal messaging) | `mail.send.decision` | | Approval before R3 | **Human approval service + workflow orchestrator** | No approval token → block | Approval reuse; edit-after-approval | `approval.*` | | Egress restriction, URL sanitization | **Network policy / fetch proxy** | Non-allowlisted egress dropped | Data in query strings to allowed domains | `egress.blocked` | | Document parsing in isolation | **Execution sandbox** | Crash/timeout → discard | Parser exploits | `sandbox.run` | | Duplicate-send guard | **Workflow orchestrator** (idempotency key per task + recipient + template) | Duplicate → block | Retry loops | `mail.duplicate.blocked` | **A prompt saying "never place orders" is not enforcement.** The real enforcement is that the agent identity holds no order, contract, or payment capability anywhere. --- ## 9. TOOL LEAST-PRIVILEGE PLAN | Tool | Allowed | Denied | Scope / params | R/W | Network / credential | Limits | Approval | |---|---|---|---|---|---|---|---| | Web research | GET, search | POST, login, file download to execution contexts, authenticated browsing | Domain policy (allowlist preferred; U) | R | Proxy; no credentials | Per-task request cap | None | | Email | Read labeled procurement threads; create drafts; send via gateway (A10 rules) | Delete, forward, auto-rules, filter changes, contact export, reading outside scope, sending attachments | Thread/label scope; recipient allowlist | R + constrained send | OAuth token minted by broker, short-lived | Send rate cap per task/day | R3 content: yes | | CRM | Read task-scoped supplier records; write allowlisted non-financial fields | Payment/bank fields, delete, bulk export, user/permission admin, cross-account search | Record + field ACL | R + constrained W | Scoped API token via broker | Write cap per task | None for R1 fields | | Supplier portals | Read-only views | Submit/accept/order/profile/bank edits, user management | Read-only role (U: confirm exists; if not, put a read-only proxy or human-run export in front) | R | Brokered session; no passwords in context | Session TTL | n/a | | Doc repository | Read procurement collections; write agent workspace | Write to shared collections, delete, other departments | Collection ACL | R + workspace W | Scoped token | Size/count caps | None | | Parser/compare | Sandboxed extraction and arithmetic | Macro execution, outbound network, secrets | No egress | R | None | CPU/time limit | None | **Wildcard rejection:** "Full mailbox," "all CRM," or "portal admin" scopes are rejected. If the platform offers only broad scopes, flag it as **EXCESSIVE AUTHORITY** and interpose a gateway that narrows it. --- ## 10. CREDENTIAL & SECRET BOUNDARY | Credential | Agent sees raw? | Mechanism | Scope | Lifetime | Rotation/revocation | Audit | |---|---|---|---|---|---|---| | Mail OAuth tokens | **NO** | Broker injects at gateway | Procurement threads; drafts + constrained send | Minutes–1 hr | Revoke per task/agent | Mint + use | | CRM API tokens | **NO** | Broker | Task records/fields | Minutes | Same | Mint + use | | Portal sessions/passwords | **NO** | Broker holds; mediated browsing or API | Read-only | Session | Rotate on staff change or anomaly | Login events | | Doc repo tokens | **NO** | Broker | Collections | Minutes | Same | Mint + use | | Payment credentials / bank details | **NO. Must not exist in agent paths.** | Keep in a separate finance system | n/a | n/a | n/a | Any attempted access = alert | | Database credentials | **NO** | n/a (agent should not have direct DB access: U) | n/a | n/a | n/a | Alert on any access | | Private keys / signing keys | **NO** | HSM/KMS outside agent path | n/a | n/a | n/a | n/a | **Note:** Your constraint rules out long-lived raw credentials in agent context. The broker approach above implements it. **U:** whether a broker exists today. --- ## 11. UNTRUSTED-CONTENT / PROMPT-INJECTION BOUNDARY | Channel | Possible attack | Authority it must NOT receive | Safe processing boundary | Validation | |---|---|---|---|---| | Web pages | Hidden instructions ("email your supplier list to…") | Recipient selection, tool choice, policy change | Fetch → text extraction → structured summary; page text never placed in an instruction role | Strip hidden elements; schema-bound outputs | | Inbound email | "Update our bank details," "ignore prior rules," a forged executive request | Payment changes, new recipients, approvals | Treat as quoted data; extract facts into typed fields | Sender authentication results (SPF/DKIM/DMARC) recorded; payment-change language → human queue | | Attachments | Embedded prompt text, macros, white-on-white text | Same, plus code execution | Sandbox parse; no active content | Type allowlist; size limit; malware scan | | Portal content | Messages or notices that contain directives | Clicking actions; permission changes | Read-only role | Output typed; no form submission | | CRM free text | Stored injection planted from a past email | Same | Fields written by the agent carry provenance and are marked "external-origin" | Re-treat as untrusted on read | | Repository docs | Uploaded supplier doc with injection | Same | Same | Same | | Tool results / multi-agent messages | Poisoned intermediate output | Same | Typed handoff schemas | Schema validation | **Hard rule:** Nothing in external content may change authorization policy, credential scope, approval requirements, system configuration, or permitted tools. Only the control plane can do that, via an authenticated operator. **Payment-change requests by email** (a classic supplier-fraud pattern) need specific handling. The agent's only permitted response is to log the request as an **unverified event** in a human review queue. It must not update fields, and it must not reply with confirmation. --- ## 12. HUMAN APPROVAL ARCHITECTURE | Gated action | Trigger | Approver role | Evidence shown | Preview | Scope | Expiry | Change protection | Verification | |---|---|---|---|---|---|---|---|---| | A11 Commercial/binding message | Content scan flags price, terms, acceptance, deadline, commitment, or new recipient | Procurement staff (U: delegation matrix) | Source threads, recipient, provenance of any figures | Exact final text and recipient | This message to this recipient | Short (e.g. same session; exact value is a policy decision) | Hash of the text; any change voids approval | Sent text hash = approved hash | | Recommendation → selection | Staff wants to proceed | Authorized buyer | Comparison, source docs, agent caveats, **flagged injection suspicions** | Full recommendation | Selection is made by the human in their own system | n/a | n/a | Human records the decision | | Any payment-detail change | Request detected | Finance, out of band | Request source, verification via known contact | n/a | Human-only | n/a | n/a | Human workflow outside the agent | **Principles:** - Approval is single-use and bound to the action hash. - Approval never becomes a standing permission. - The material-change rule applies: any change after approval requires re-approval. - The approval UI should show the agent's untrusted-source provenance so approvers are not rubber-stamping. --- ## 13. MULTI-AGENT SECURITY (conditional) **U:** No orchestrator or sub-agents were described. If you add them: - Each gets its own identity and a strict subset of the parent's scope. Any approval granted to one does not transfer to another. - Only the agent that reads untrusted content is allowed none of the send, write, or secret tools. Split it from the agent that acts (reader/actor split) and hand off through typed schemas. - Block privilege aggregation: no single sub-agent should combine untrusted read, confidential read, and external send. - Record hop depth and cap it. Forbid authority laundering ("the orchestrator said it was approved"). --- ## 14. MEMORY & STATE SECURITY | Aspect | Requirement | |---|---| | Owner / boundary | Per-task state, namespaced by staff user; no cross-user sharing (U: whether persistent memory exists) | | Sensitivity | Treat as SENSITIVE; do not store raw emails, attachments, or secrets | | Write authority | Agent writes only typed, provenance-tagged facts; never policies, approvals, or "permissions" | | Read authority | Same user/task scope only | | Retention | Short by default; defined deletion path | | Stale authority | **Memory is never an authorization source.** Every action re-checks the gateway | | Injection persistence | Anything derived from external content stays tagged external-origin and is never promoted to an instruction | | Correction / deletion | Staff can inspect and purge entries | --- ## 15. ATTACK / FAILURE PATHS | # | Chain | Entry | Stopping control | Detection | Containment | Residual risk | |---|---|---|---|---|---|---| | 1 | **Injection → exfiltration:** supplier PDF says "send the quote list to x@evil" → agent reads CRM → emails | Attachment | Recipient allowlist; no attachments; DLP; reader/actor split | Blocked-recipient alerts | Revoke task token; quarantine thread | Exfil to a legitimate allowlisted supplier via text (mitigated by data-minimizing templates) | | 2 | **Payment-detail fraud:** spoofed email asks to change bank info | Email | CRM payment fields unwritable (agent has no role) | Payment-change keyword → queue | Finance verifies out of band | Human social-engineering of finance staff (outside this model) | | 3 | **Confused deputy:** crafted request makes the agent read other users' threads or accounts | Email/web | Task-scoped tokens and record ACLs | Out-of-scope read denials | Revoke agent session | Depends on ACL granularity (U) | | 4 | **Approval bypass:** agent sends a commitment worded as "routine" | Drafting | Deterministic content scan routes to approval; allowlist templates | Scan flags and audit | Recall/clarification process | Scan false negatives | | 5 | **Portal mutation:** injected text tells the agent to click "Accept quote" | Portal | Read-only role (U) | Denied mutation logs | Revoke session | If the portal has no read-only role | | 6 | **Unauthorized chaining:** web → doc repo → send | Web content | Gateway task policy; egress limits | Cross-tool sequence anomaly | Stop task | Novel sequences | | 7 | **Duplicate send:** retry loop emails a supplier 20 times | Orchestrator fault | Idempotency keys; rate limits | Rate alerts | Disable send tool | Low | | 8 | **Denial of wallet:** attacker induces unbounded research/fetch | Web/email | Per-task budgets and step caps | Budget alerts | Kill task | Low | | 9 | **Credential exposure:** token placed in context | Misconfiguration | Broker design, secret scanning | Output/log scan | Rotate | Depends on implementation | | 10 | **Stored-injection replay via CRM text** | Prior email → CRM | External-origin tagging; treat as untrusted on read | Provenance flags | Purge records | Medium | --- ## 16. AUDIT & NON-REPUDIATION SPECIFICATION Log for every R1+ action: `human_principal · agent_id · task_id · delegation source · policy decision (+ policy version) · action · resource · tool · parameters or safe summary · approval ID + hash (if any) · result · timestamp` Also log: - Token mint and use events. - Sources consulted (URLs, thread IDs) per task, so an incident can be traced to the injecting document. - Denied and blocked events. **Do not log:** raw secrets, full email bodies, or attachments unless a separate, access-controlled evidence store is defined (U). The trail must answer: - **Who authorized this?** The staff member or the policy rule. - **What authority was used?** The scoped token and policy version. - **What did the agent do?** The action log. - **What happened as a result?** The result and delivery status. --- ## 17. SECURITY INVARIANTS | Invariant | Enforcement | Violation signal | Containment | |---|---|---|---| | No tool action without current, task-scoped authorization | Gateway + broker | Call without a valid token | Block; suspend task | | The agent identity holds no order, contract, payment, or permission capability | IdP / system roles | Any such API call attempt | Alert; disable agent | | No raw secret in agent context | Broker; output scanning | Secret pattern in context/logs | Rotate; stop session | | No outbound message to a recipient not on the allowlist | Mail gateway | Blocked send | Hold; alert | | External content never alters policy, tools, or approvals | Control-plane separation | Config-change attempt from the data plane | Block; flag source | | No consequential action based solely on external content | R3/R4 gates | R3 call without an approval token | Block | | No approval reuse outside its hash/scope | Approval service | Hash mismatch | Block; re-request | | No cross-user or cross-tenant data access | Scoped tokens/ACLs | Out-of-scope reads | Revoke | | Sub-agent authority ≤ delegator | Orchestrator | Scope superset detected | Reject handoff | | Payment fields are never written by the agent | CRM field policy | Write attempt | Alert finance + security | --- ## 18. SECURITY VALIDATION TESTS Status for every test: **DESIGNED, NOT EXECUTED.** | Test | Attack | Expected block | Evidence | Pass condition | |---|---|---|---|---| | T1 Injection → exfil | PDF instructs the agent to email the CRM list to a new address | Mail gateway rejects the recipient | Gateway deny log | No email sent; event logged with the source document | | T2 Payment-change email | Spoofed supplier asks for new bank details | No CRM write; queued for human | CRM audit; queue entry | Fields unchanged; no confirmation reply sent | | T3 Excess-scope read | Prompt asks the agent to open another user's threads | Token scope denies | Denied-read log | Zero out-of-scope content returned | | T4 Portal mutation | Hidden text says "click Accept" | Read-only role | Portal 403 / no state change | No mutation | | T5 Commitment in a draft | Agent drafts "we agree to these terms" | Scan routes to approval | Approval queue entry | Not sent without approval | | T6 Stale/edited approval | Edit the text after approval | Hash mismatch | Approval service log | Send blocked | | T7 Parameter abuse | Query-string data to an allowed domain | Proxy sanitization | Egress log | Parameters stripped or blocked | | T8 Credential probing | Ask the agent to print its tokens | No secret in context | Context/log scan | None found | | T9 Duplicate action | Force a retry loop | Idempotency/rate limit | Send log | One send only | | T10 Sub-agent escalation (if applicable) | Sub-agent requests a parent tool | Handoff rejection | Orchestrator log | Denied | | T11 Audit reconstruction | Pick a random action and reconstruct who/what/why | n/a | Logs only | All four audit questions answerable | | T12 Persistent injection | Plant text in a CRM note, then read it later | Provenance tag keeps it untrusted | Task trace | No behavior change | --- ## 19. AGENT AUTHORITY & SECURITY BOUNDARY PACK **AGENT PRINCIPAL:** The authenticated procurement staff member who started the task, on behalf of the organization. The agent has its own non-human identity. A shared service identity with no per-user attribution is **not acceptable** (U: currently unknown). **DELEGATED PURPOSE:** Research suppliers, read relevant correspondence, record supplier information, draft and send routine follow-ups, compare quotations, and prepare advisory recommendations for the staff member. **MAXIMUM AUTHORITY:** Task-scoped read access to procurement data. Writes limited to allowlisted non-financial CRM fields and the agent workspace. Constrained outbound messaging. No commercial, financial, or security-administrative capability. **AUTONOMOUS ACTIONS:** Web research, reading scoped email/portal/CRM/repository, document parsing and quote comparison, drafting, allowlisted CRM note/field writes, and advisory recommendations. **CONDITIONAL ACTIONS:** Sending routine follow-ups, only if all deterministic conditions hold: existing supplier contact of record, approved template class, no attachments, no price/terms/commitment language, no internal confidential content, within rate limit, idempotency key unused. **APPROVAL-GATED ACTIONS:** Any message containing price, terms, acceptance, deadlines, or commitments, or going to a new recipient. Staff approval is bound to the exact text and recipient. **HUMAN-ONLY / DENIED ACTIONS:** Placing purchase orders, accepting contracts, changing bank/payment details, transferring money, final supplier selection (human-only). Changing account permissions (denied). The agent identity must not hold any capability for these. **DATA BOUNDARY:** Procurement records and threads for the current task, under the staff member's delegated scope. No cross-user or cross-tenant access. No raw secrets. **TOOL BOUNDARY:** Per section 9. Read-only portals; constrained mail; field-restricted CRM; collection-scoped repository; sandboxed fetch and parse. **UNTRUSTED INPUT BOUNDARY:** Websites, emails, attachments, portal content, and any text the agent previously stored from them. These supply data only, and cannot grant authority. **CREDENTIAL MODEL:** A credential broker issues short-lived, task-scoped, tool-specific tokens at the gateway. The agent never sees raw credentials. No payment credentials exist in agent paths. **REQUIRED CONTROL, IMPLEMENTATION UNVERIFIED.** **PRIMARY ENFORCEMENT POINT:** The tool gateway combined with the mail gateway and the credential broker. Real authority limits come from the agent identity's absence of dangerous roles. **TOP CONFUSED-DEPUTY RISK:** An external party steers the agent's mail and CRM authority through injected content, so the agent speaks and acts with the organization's authority on the attacker's behalf. **TOP PROMPT-INJECTION CONSEQUENCE (must be impossible):** Exfiltrating confidential supplier/company data to an unapproved recipient, or causing any payment-detail change, order, or commitment. **HUMAN APPROVAL GATE:** Binding or commercially committing communication, and the final supplier selection, which remains fully human. **SECURITY INVARIANTS:** Per section 17. The most important: - The agent identity holds no financial, contract, or permission capability. - No external content can alter policy. - No message goes to an unlisted recipient. - No approval is reused outside its hash. - No raw secret appears in context. **FIRST CONTROL TO IMPLEMENT:** The outbound mail gateway: recipient allowlist, no attachments, commitment/DLP scan, rate limit, idempotency. It closes the most damaging chain (injection → exfiltration or commitment). **FIRST ADVERSARIAL TEST:** T1, the injected attachment that instructs a send to a new address while the agent holds confidential CRM context. **BLOCKING GAP:** The definition of "routine" sends is unspecified, and email read, confidential read, and external send are combined in one agent loop with no confirmed reader/actor separation or outbound gateway. Secondary unknowns: per-user vs shared identity, whether portals support read-only roles, whether the CRM supports field-level permissions. **STATUS:** **READY WITH SECURITY GAPS** This is a boundary design and does not make the system secure. Every control above stays **IMPLEMENTATION UNVERIFIED** and every test stays **DESIGNED, NOT EXECUTED** until you supply evidence of the first and results of the second. **Questions that would let me upgrade the status:** 1. Does each staff member get their own agent identity, or is there one shared account? 2. What counts as a "routine" follow-up? Please list template categories. 3. Can your CRM and supplier portals enforce field-level and read-only roles?