IT Operations Agent: An Injected Wiki Page and a Service Account That Can Do Everything
An internal IT-operations agent handles tickets: it reads a wiki, queries a CMDB, restarts services, and emails users. It authenticates to backends with a single OCI IAM service account holding broad rights in the operations compartment. Authorization is coarse - any employee can ask the agent anything, and the agent acts with its own service-account rights. Last month a contractor-edited wiki page contained text instructing the agent to email a config file to an external address; the attempt was blocked only by an SMTP egress rule. An auditor separately found no record of which human triggered a restart, and 14 restarts in one week traced to one user experimenting. There is no per-role tool allowlist. Prompt and response logs are retained for 7 days, and retrieved documents are pasted into the context unfiltered.
1. Threat-model this system. Identify the two distinct failure classes and the controls that address each.
Read the worked answer
Failure class 1: indirect prompt injection. The wiki is attacker-writable content that reaches the model as instructions. The agent treated document text as commands, and only a network rule prevented exfiltration. Controls:
- Treat retrieved content as data: wrap it in explicit delimiters, label it untrusted, and instruct the model not to follow instructions found inside - necessary but insufficient on its own.
- Remove or strictly allowlist the agent's outbound capabilities. Email should go only to internal domains from a fixed template; no attachment of retrieved file content.
- Human confirmation for any side-effect tool whose target is derived from retrieved text.
- Egress allowlisting at the network layer, which is what saved this incident - keep it and monitor attempts.
- Scan and quarantine wiki pages containing injection patterns; restrict write access to the ops wiki.
Failure class 2: confused deputy and missing attribution. The agent is an authorization bypass: it wields rights no requester has individually. That is a governance defect independent of injection.
- Authenticate the requester and evaluate authorization per request against their role, not the agent's identity.
- Restart in production requires role entitlement plus an approved change ticket.
Both classes must be fixed; hardening the prompt does nothing for the second.
2. Redesign identity and least privilege on OCI for this agent, and specify how restart authorization should work end to end.
Read the worked answer
Identity. Stop using one shared service account with broad rights. Two supported patterns:
- Act as the requester: exchange the user's token for a short-lived token scoped to the needed resource, so OCI IAM evaluates the human's policies.
- Entitlement service in front: the agent calls an internal service that checks the requester's role and returns a narrow, short-lived credential or performs the action itself.
Least privilege. Move the agent into its own compartment. Use dynamic groups matching the workload's instance or resource principal, and policies scoped by compartment, resource type, and tags (for example, manage only instances tagged env=dev or tier=app, never tenancy-wide). Separate compartments per environment, with production write access reachable only through the approval path. Secrets and credentials live in OCI Vault with rotation and short TTLs, not in the agent's configuration.
Restart flow. Request arrives with user identity → role check against the service catalog → production requires a linked, approved change ticket → approval recorded in an immutable log → short-lived credential issued for that instance only → action executed → result and approver written to the audit record. Break-glass access exists, is time-boxed, and pages the on-call lead when used.
Verify with a negative test suite: a helpdesk user requesting a production restart must be denied regardless of how the request is phrased.
3. Specify logging, detection, and incident response, given that 7-day retention already proved inadequate.
Read the worked answer
What to log per request. Requester identity, session id, tool name, arguments, target resource, retrieval document ids and versions, approval id, model and policy version, decision, and outcome. Record retrieved-content hashes so an injected page can be identified after the fact. Redact secrets and PII at write time, and store in an immutable bucket with retention set by policy, not by log-rotation convenience - 7 days cannot support an investigation that surfaces a month later.
Detections.
- Restart volume per user and per service, with an alert at a small multiple of baseline; 14 restarts by one user should page, not appear in a monthly report.
- Outbound email attempts to external domains, or with attachments.
- Retrieval of documents flagged sensitive or newly edited by non-ops accounts.
- Injection-pattern matches in retrieved content.
- Approval-gate bypass attempts and denials by tool.
Incident response. Per-tool kill switches so email or restart can be disabled without taking the agent down. Revoke and rotate the credential involved; quarantine the offending document and invalidate cached copies; replay the session from logs to establish what the agent saw and did; notify security and, if data left, the privacy office. Then convert the incident into a regression test in the release suite so the same injection is caught before the next deploy.