Cyber Decision LedgerTechnology
AI / ML systems
19 public Decision Records in the whole ledger carry this label. Back to the full Ledger →
Decision Records
Privileged automation governance for externally acting AI agents
AI agents that can read sensitive business content and act externally should be governed like privileged automation: use task-scoped identities, default-deny outbound paths, require human approval for external sends, bulk export, credential use, code execution, and irreversible actions, isolate tool use from production secrets, and log content retrieval, tool calls, destinations, and data volume.
When AI agents can read sensitive business content and act outside the workspace, govern them as privileged automation. Use scoped identities, deny unnecessary outbound paths, require approval for high-impact actions, isolate tool execution, keep production secrets out of agent workspaces, and log retrieval and tool activity.
Govern AI agents as privileged connector infrastructure
Enterprise AI agents and assistants should be governed as privileged OAuth clients and connector brokers. Disable unused or overbroad connectors, limit write, administrator, export, and payment actions, require server-side object authorization and admin approval for high-risk grants, rotate or re-consent tokens where warranted, and log user-to-agent-to-tool actions alongside SaaS audit trails.
Organizations should treat enterprise AI agents and assistants as privileged connector infrastructure: review and disable unnecessary connectors, limit high-risk actions, require authorization and approval for sensitive grants, refresh tokens where warranted, and retain audit trails that connect users, agents, and downstream tools.
AI agent execution containment
Treat coding and browser AI agents as privileged execution infrastructure. Validate vendor advisories and update affected tools, run agents in constrained workspaces, isolate agent CI runners, remove long-lived secrets from agent-visible environments, deny tunnel or persistence creation from agent ancestry by default, and keep browser agents away from authentication, finance, and admin workflows.
Security teams should manage coding and browser AI agents like privileged execution paths: constrain workspaces, isolate CI runners, remove long-lived secrets, restrict sensitive browser workflows, and block tunnel or persistence creation from agent-launched processes unless explicitly approved. Vendor-specific patch statements should be tied to confirmed advisories.
Govern privileged AI agents as untrusted automation
Yes. Treat AI agents with CI/CD, cloud, browser, or internet authority as untrusted automation by removing long-lived secrets, using least-privilege tokens, separating read-only from write-capable agents, requiring human approval for privileged actions, blocking production credentials, filtering egress, logging tool calls, and alerting on unexpected workflow or secret-handling behavior.
Treat AI agents that can touch CI/CD, cloud, browser, or internet workflows as untrusted automation: remove long-lived secrets, use least privilege, require human approval for privileged actions, block production credentials, control egress, log tool calls, and monitor unusual workflow or secret-handling behavior.
AI-mediated CI privileged automation controls
Treat AI agents and AI-mediated CI workflows as untrusted automation principals. Do not allow untrusted issues, comments, model output, or agent messages to directly drive privileged CI/CD or cloud actions; disable autonomous merge, deploy, and remediation authority until reviewed; use least-privilege short-lived credentials, deny-by-default sandbox egress, and human approval for privileged steps.
Treat AI agents and AI-mediated CI workflows as untrusted automation. Keep untrusted content and model output from directly triggering privileged build, deploy, cloud, or remediation actions. Require human approval for privileged steps, use short-lived scoped credentials, isolate secrets, and deny sandbox egress by default.
AI agent runtime isolation
Govern enterprise AI agents and evaluation sandboxes like privileged automation runtimes: use scoped identities, restrict secrets, control egress, isolate workspaces, narrow tool permissions, log activity, and require human approval for sensitive external actions.
AI agents and evaluation sandboxes that can use tools, networks, repositories, or external services should run with CI-runner-grade containment: scoped identity, default-deny or tightly controlled egress, no default secret access, disposable workspaces, limited tools, audit logging, and human approval for sensitive actions.
AI model keys need production access controls
Treat AI systems, model-service keys, and agentic workflows as production access paths. Rotate and scope keys, store them in managed vaulting, add spend and anomaly controls, inventory agent workflows, restrict tool permissions, sandbox code execution, log agent activity, and keep production secrets out of AI workspaces.
AI systems that can call tools, run code, or use model-service keys should be governed like production access paths: scope and vault credentials, monitor spend and anomalies, restrict tools, sandbox execution, log agent activity, and avoid exposing production secrets.
Default-deny boundaries for AI security agents
Isolate agent runs with default-deny egress and mediated tools, block direct production DNS, internet, SaaS, package publishing, and standing secrets, and require explicit approval for exploit execution, credential use, package publication, and outbound connections.
Organizations running AI security evaluations or AI-assisted offensive testing should default-deny agent access to real systems: use mediated tools, block direct production and internet paths, remove standing secrets, and require explicit approval for exploit execution, credential use, package publication, and outbound connections.
Govern AI agents and SaaS connectors as privileged authority paths
Organizations should govern AI agents and SaaS connectors as privileged authority paths. They should disable or tightly scope agent creation, require admin approval and audit for new agents and connectors, reduce OAuth scopes, use least-privilege service identities, add egress controls, treat retrieved content as untrusted input, strip hidden comments, and require human approval before write, merge, credential, or outbound actions.
Treat enterprise AI agents and SaaS connectors as systems that can exercise authority, not as ordinary chat features. Limit who can create and connect them, minimize scopes, audit changes, constrain egress, treat retrieved content as untrusted, remove hidden instructions where feasible, and require human approval before sensitive actions. Avoid presenting named incident anecdotes as verified compromises unless primary sources are attached.
Controls for privileged AI and MCP-style agents
Disable or tightly constrain AI review and MCP-style agents when they can act on repositories, pipelines, secrets, wikis, or work items. Strip hidden untrusted content from context, log tool calls, rotate reachable secrets, and issue dedicated least-privilege agent identities instead of using ambient human authority.
When AI review or MCP-style agents can act on source code, pipelines, secrets, work items, or wikis, constrain or disable that reach until least-privilege identities, context filtering, tool-call logging, and secret rotation are in place. Avoid product-specific affected-version or exploit claims unless authoritative advisory evidence is added.
Limit OAuth apps and AI agent delegated authority
Disable unapproved OAuth apps and broad AI agent connectors, revoke grants and refresh tokens where exposure exists, require fresh explicit authorization with admin policy checks, issue scoped short-lived identities, and require semantic confirmations for high-risk actions.
Do not let unapproved OAuth apps or AI agent connectors retain broad delegated access after weak consent flows. Revoke unapproved grants, require fresh explicit authorization with admin policy checks, use scoped short-lived identities, and require clear user confirmation for high-risk actions.
Immediate guardrails for AI development and evaluation workflows
Restrict AI evaluation, data-processing, agentic tool use, and coding-assistant workflows to reduce blast radius. Default-deny internet egress from sandboxes, use disposable least-privilege identities, quarantine untrusted datasets and model artifacts, require policy and human approval for mutating tools, and keep coding assistants read-only by default in sensitive repositories.
Organizations using AI evaluation sandboxes, AI data pipelines, agentic development tools, or coding assistants should reduce tool authority now: restrict egress, use least-privilege disposable identities, quarantine untrusted inputs, require approval for mutating actions, and keep sensitive repositories read-only by default for assistants.
ServiceNow AI Platform exploitation triage before notification
Do not treat exploitation risk by itself as a breach-notification event. Preserve tenant, admin, audit, prompt, output, ticket, and credential evidence; conduct governance and vendor-risk triage; and escalate to notification analysis only if unauthorized access or data exposure is found.
Reported exploitation risk in a workflow or AI platform should trigger evidence preservation and tenant-specific triage. It should not be described as a reportable breach unless unauthorized access or data exposure is confirmed through the review.
AI workflow containment based on execution authority
Do not impose a blanket AI tooling ban. Remove exposed AI workflow services from untrusted access paths, isolate code-executing agents, restrict credentials and egress, require human approval for dangerous actions, and validate recovery of model and data assets.
AI tooling should be contained according to exposure and execution authority: keep internet-exposed workflow services off untrusted paths, isolate tools that can run code, restrict secrets and egress, and require human approval for high-risk actions rather than disabling all AI use.
Containment for untrusted developer code near secrets
Contain where untrusted code can execute near secrets. Freeze nonessential dependency updates, gate install-time scripts where feasible, rotate secrets on developer or CI systems that ran unreviewed code, review recent dependency and workflow changes, and keep autonomous AI agents away from production credentials unless sandboxed.
Focus response on places where untrusted code ran with access to secrets or trusted automation. Temporarily limit nonessential dependency changes, control install-time scripts where feasible, review recent workflow and dependency changes, rotate exposed credentials, and require sandboxing before AI agents can reach production credentials.
Harden and hunt exposed AI developer endpoints
Inventory MCP, Ollama, and OpenAI-compatible endpoints; bind them to localhost, VPN, or private networks; require auth or mTLS; remove secrets from assistant config files; block agent/tool runtimes from reaching cloud metadata services unless explicitly needed; and hunt external probes and metadata calls from agent hosts.
Inventory AI developer endpoints such as MCP, Ollama, and OpenAI-compatible APIs; bind them to localhost, VPN, or private networks; require auth or mTLS; remove secrets from assistant configuration files; block unnecessary cloud metadata access from agent/tool runtimes; and hunt for external probes and metadata calls from agent hosts.
Sandbox privileged AI coding agents and MCP-connected tools
Disable or sandbox privileged AI coding agents and MCP-connected tools that can execute shell commands, write outside workspaces, auto-approve tools, reach networks, reuse browser sessions, access credentials, install packages, push or merge code, invoke cloud administration, or access secrets-bearing CI/CD contexts; restore only with sandboxes, ephemeral credentials, explicit high-risk approvals, and prompt-to-tool logging.
Privileged AI coding and MCP-connected tools should be disabled or sandboxed when they can execute commands, access secrets, write outside a workspace, use network egress, reuse sessions, install packages, alter repositories, invoke cloud-admin actions, or access CI/CD secrets. Restore capabilities only with project sandboxes, ephemeral credentials, explicit approvals, and complete prompt-to-tool logging.
Authorize temporary emergency controls for identity, mobile, edge, and AI workflow exposure
Approve concrete 72-hour authority and downtime tolerance today: force identity controls for finance and admin users, allow security to quarantine non-compliant mobile devices without business-unit delay, and authorize emergency change windows for edge and AI workflow systems, with rollback and business-risk ownership.
Boards or executive teams facing the cited identity, mobile, edge, and AI workflow exposure set should consider a time-boxed emergency-change posture: authorize stronger controls for privileged and finance identities, permit quarantine of non-compliant managed mobile devices, and approve emergency windows for exposed edge or AI workflow systems instead of relying only on monitoring uplift.
Treat exposed AI workflow environments as credential-exposure risk
Inventory Langflow, Marimo, AI IDE, notebook, and browser-agent deployments. For exposed or secrets-connected systems, remove public exposure, patch or isolate Marimo-style deployments until verified fixed, rotate touched cloud/API credentials, restrict secret-store and authenticated-app access, and log agent/tool activity.
Inventory AI workflow, notebook, IDE, and browser-agent deployments, prioritizing systems exposed to untrusted networks or connected to production secrets. Remove public exposure, isolate where a verified fix is not available, rotate touched credentials, restrict secret-store access, and log agent/tool activity.