AI Agent Security in 2026: How to Govern Shadow Agents Across Cloud and DevOps

An AI agent can become operational long before anyone calls it an application. A developer gives a coding assistant a repository token. An operations team connects a model to an incident queue. A finance analyst builds a workflow that reads invoices and updates a spreadsheet. Each experiment may look small. Together, they create a population of software actors that can reach code, data, cloud APIs, and business processes.

That is the shadow agent problem. It is not simply that an agent might behave badly at runtime. It is that the organization may not know the agent exists, who owns it, what approved purpose it serves, or whether its access changed after review. Effective AI agent security therefore starts before prompt filters and monitoring. It starts with discovery, accountable ownership, an approval path, a durable inventory, and change control that works at DevOps speed.

This article focuses on that governance layer. For the technical controls applied while an approved agent is running, see PChatGPT’s separate guide to AI agent runtime security. For the identity foundation beneath agents, service accounts, and automation, the companion article on non-human identity security explains credential and workload identity concerns in more depth.

What Makes an Agent a Shadow Agent?

A shadow agent is an autonomous or semi-autonomous AI workflow that operates outside the organization’s expected registration, review, and ownership process. It may be a hosted agent product, a script around a model API, an IDE assistant with action permissions, a CI bot, an automation-platform workflow, or a service that delegates tasks to other agents. The label describes its governance status, not its sophistication.

A sanctioned product can still produce shadow deployments. A centrally purchased assistant may be approved for drafting but not for connecting to production repositories. A team may add a new connector without updating the original review. Likewise, an experimental agent is not necessarily shadow technology if it is registered, isolated, time limited, and owned. The practical question is: can the organization explain and control this specific deployment?

Traditional software inventory methods often miss agents because the visible model is only one component. The actual system includes prompts and policies, tools, connectors, identities, data sources, memory stores, orchestration code, deployment environments, and human approval steps. An agent can also act through a user’s delegated authorization, so searching only for service accounts will leave gaps.

Why Governance Must Come Before Runtime Hardening

Runtime safeguards matter, but they assume someone knows what to safeguard. An unregistered agent may never receive a scoped identity, an evaluation dataset, or a log retention decision. Its builder may leave the company while its scheduled workflow continues. A team may copy a prototype into production and preserve a broad development token because no release gate asks for an agent record.

The NIST AI Risk Management Framework organizes AI risk work around Govern, Map, Measure, and Manage. Its voluntary framework covers the design, development, use, and evaluation of AI systems. The companion Generative AI Profile provides suggested actions for generative AI risk. For an agent program, that lifecycle view translates into a simple operating principle: registration is not a one-time security ticket. The agent’s purpose, context, risk, evidence, and controls must remain connected as the system changes.

OWASP’s Top 10 for Agentic Applications for 2026 addresses agents that plan, act, and make decisions across complex workflows. Its broader Agentic AI Security Initiative covers autonomous agents and multi-step workflows. These resources are useful for threat modeling, but a threat model cannot help an agent that never enters the review process. Discovery and registration are the bridge between policy and technical security.

Discover Agents by Following Evidence, Not Product Names

Do not begin with a fixed list of vendors or with a survey that asks employees whether they use agents. Surveys can reveal intent, but they cannot establish a dependable inventory. Search for evidence of agency: model calls combined with tools, credentials, scheduled execution, state, delegation, or write access.

Cloud and identity evidence

Review newly created roles, service accounts, managed identities, API keys, OAuth grants, federated identities, and secret-manager entries. Names containing terms such as agent, bot, copilot, assistant, model, or automation are useful leads, not proof. Also look for identities created by unusual principals, roles with no owner tag, interactive user tokens used by scheduled workloads, and identities whose activity crosses repository, ticketing, data, and cloud services.

Cloud records provide complementary views. AWS states that IAM last-accessed information can help identify unused permissions, while CloudTrail is the authoritative source for API calls and whether requests succeeded or were denied. Microsoft documents that Azure Activity Log can show managed identity updates and role assignment changes, while Microsoft Entra sign-in logs expose managed identity authentication attempts. Google Cloud’s security log analytics guidance shows how Admin Activity logs can identify service accounts or keys created by a non-approved identity. These are valuable discovery signals, but they require interpretation. A service account may support an ordinary application, and an agent may operate through a human account.

DevOps and source evidence

Search code hosts for model SDK imports, model endpoints, agent framework packages, MCP configuration, tool definitions, system prompts, vector-store setup, and environment variable names associated with model providers. Search CI/CD systems for marketplace actions, reusable workflows, pipeline variables, runners, webhooks, and scheduled jobs that invoke models or agent CLIs. Examine infrastructure as code for model resources, identity bindings, secrets, and network routes.

Repository scanning should create leads for review, not automatic accusations. A dependency in a lockfile does not prove an active deployment. A prompt file may belong to a tutorial. Correlate source evidence with deployments, identity use, network records, model-provider administration, and a conversation with the team.

SaaS, browser, and procurement evidence

OAuth consent records, enterprise app catalogs, browser extension inventories, expense data, vendor sign-in records, API gateways, and SaaS audit logs can expose agent products that never touch a cloud subscription. Procurement can identify contracts, but free tiers and user-authorized integrations often bypass purchasing. Security teams should give staff a low-friction way to register useful experiments without treating every disclosure as misconduct. If registration feels like a trap, shadow use becomes harder to see.

Build a reconciliation loop

Send all leads into a reconciliation queue. Match each lead to an existing agent record, mark it as a false positive, or open an ownership investigation. Preserve the evidence source and time observed. Re-run discovery on a schedule and after major platform onboarding. The useful output is not a giant list of strings that mention AI. It is a smaller list of deployments that need an owner or a decision.

Create an Inventory That Can Answer Operational Questions

A spreadsheet can work at the beginning, but the record must eventually connect to the systems that create and change agents. Store the inventory in a service catalog, configuration database, governance platform, or versioned repository with an API. Choose the system your engineering and operations teams already use, then define a required schema.

Each deployment record should include:

• Identity: a unique agent ID, display name, environment, lifecycle state, and links to code and deployment resources.
• Accountability: a named technical owner, business owner, support group, escalation route, and review date. A team alias alone is not enough unless someone is accountable for that queue.
• Purpose and boundary: the approved use case, intended users, prohibited actions, data classifications, jurisdictions where relevant, and expected business impact.
• Components: model provider and model family, orchestration framework, prompts or policy package, tools, connectors, memory, knowledge sources, and downstream agents.
• Access: cloud roles, service accounts, delegated user scopes, secrets, repositories, databases, SaaS permissions, network destinations, and production access.
• Control evidence: threat model, privacy review, evaluation results, approval record, exception record, logging destination, incident runbook, and rollback method.
• Lifecycle: creation date, approval status, last observed use, material-change history, expiration date for trials, and decommission evidence.

Record relationships, not just fields. The question during an incident is rarely “Which agents exist?” It is more often “Which deployed agents use this compromised connector, this identity, this model version, or this data source?” A relationship graph makes that question answerable. It also reveals one identity shared by several agents, which obscures attribution and complicates retirement.

Separate the logical agent from its deployments. The same code may run in development and production with different data and permissions. Those are different risk objects and should have separate approval states. Keep a parent record for the shared design, then child records for each environment and business use.

Assign Ownership That Survives Team Changes

Ownership is a control, not an administrative label. The technical owner should understand deployment, dependencies, evaluations, and rollback. The business owner should be able to defend the purpose, affected users, and acceptable impact. Security, privacy, legal, data governance, or compliance functions advise and approve according to risk, but they should not become the default owner of every agent.

Define what owners must do: review access, respond to findings, approve routine updates within delegated limits, keep evaluation evidence current, participate in incidents, and retire the deployment when its purpose ends. Connect ownership to employee and team lifecycle events. If an owner changes role or leaves, the inventory should trigger reassignment. If no replacement accepts responsibility within the defined window, suspend high-risk access or retire the agent.

Give each agent an operational contact and a separate escalation path. A bot that opens pull requests at 2 a.m. needs a team that can stop it even if the original developer is unavailable. Production agents also need a documented kill mechanism that does not depend on asking the agent to stop itself.

Design an Approval Path People Will Actually Use

A single heavyweight review for every experiment encourages bypass. Instead, create lanes based on capability and impact. A local prototype using synthetic data and no external tools may qualify for self-registration with automatic expiration. A read-only internal assistant using approved data may receive a standard review. An agent that writes to production, changes access, deploys code, communicates externally, or handles regulated data needs deeper review and explicit approval.

Use an intake form that can be completed from a developer portal or repository template. Ask concrete questions: What action can the agent take? Which identity does it use? Can it modify production? Which data enters model context? What can leave the organization? Does it call third-party tools? Which human approves consequential actions? How is it stopped? Avoid vague prompts such as “Is the agent secure?”

Approval should produce a machine-readable decision with scope, conditions, approvers, evidence links, expiration, and permitted deployment environments. A “yes” for a read-only pilot is not approval for write access in production. Policy as code can then check the decision during deployment.

OpenAI’s official agent safety guidance warns that agents can still make mistakes or be tricked even with mitigations. It recommends caution in granting access, structured outputs to constrain data flow, tool approvals, guardrails, and trace graders and evals. Those recommendations support an approval decision, but they do not replace it. Governance must decide which tools and data may be connected in the first place.

Put Change Control Around Capabilities, Not Every Commit

Agent systems change frequently. Requiring a committee meeting for every prompt edit is impractical, while treating all updates as routine misses changes that alter risk. Define material-change triggers and enforce them in the delivery path.

Typical triggers include adding a tool or connector, expanding OAuth scopes, changing from read to write, reaching a new data classification, moving into production, changing model or provider, enabling memory, adding agent-to-agent delegation, changing the human approval step, exposing the agent to external users, or increasing its autonomy or execution schedule. A dependency update may also be material if it changes tool behavior or data flow.

Low-risk changes can proceed under the owner’s delegated authority if automated checks and regression evaluations pass. Higher-risk changes reopen selected reviews. Version the agent manifest, approval decision, prompt or policy bundle, tool schemas, model configuration, evaluations, and infrastructure together. The deployed version should be traceable to a commit and a decision record.

OpenAI’s agent evaluation documentation describes traces as end-to-end records of model calls, tool calls, guardrails, and handoffs, and recommends datasets and eval runs when repeatability is needed. In governance terms, evaluation evidence becomes part of a release case. Teams can compare a proposed change against approved behavior instead of relying on a demo that happened to work.

Embed Governance in Cloud and DevOps Workflows

The strongest control is close to where a deployment is created. Require an agent manifest in the repository. Validate its schema in CI. Check that its agent ID exists, the owner is active, the approval covers the target environment, required evidence is current, and requested identities and connectors match the record. Block only when a defined policy fails, and return a clear remediation message.

Apply cloud organization controls to identity creation and privilege changes. Route creation and role-assignment events to the reconciliation queue. Require owner and agent ID tags where the platform supports them. Detect credentials created outside the approved automation path. Compare observed permissions and use with the inventory, while respecting each provider’s logging limitations.

Do not make the catalog a second manual truth. Import facts from source control, infrastructure as code, deployment platforms, identity systems, and provider administration APIs where available. Let owners attest to purpose and risk decisions that machines cannot infer. This split keeps the record useful without asking engineers to copy technical fields by hand.

Handle an Unregistered Agent Without Creating Panic

Discovery is not automatically an incident. Triage the agent according to reachable systems, active credentials, data sensitivity, external exposure, and evidence of use. Preserve relevant records. Find the likely owner. If the agent has no sensitive access and is inactive, registration or orderly retirement may be enough.

If it can make consequential changes, isolate it from production actions while the team establishes scope. Revoke exposed or shared credentials when necessary, but avoid deleting evidence or breaking an unknown business process without coordination. A short containment checklist should identify the identity, disable schedules, remove high-impact tool access, preserve logs and configuration, and name a decision owner.

Offer three outcomes: approve after remediation, confine to a lower-risk sandbox, or retire. Document why. The goal is not to punish experimentation. It is to turn unknown automation into an explicit business decision.

Measure Whether the Governance System Works

Counting registered agents is not enough. Track coverage and decision quality:

• Percentage of observed deployments matched to a current inventory record.
• Percentage with active technical and business owners.
• Time from first observation to ownership and disposition.
• Percentage of production deployments whose approval scope matches observed tools, identities, and environment.
• Number and age of expired trials, overdue reviews, orphaned agents, and open exceptions.
• Percentage of material changes that passed the expected review path before deployment.
• Time required to identify every deployment affected by a connector, credential, model, or data-source issue.
• Time to suspend an agent safely during an exercise or real event.

Use metrics to improve the path, not to reward underreporting. A sudden rise in discovered shadow agents may mean detection improved or staff trust the registration process. Pair dashboard numbers with sampling: choose several approved agents and verify the code, permissions, data flow, and operational owner against the record.

A Practical First 90 Days

In the first month, name a program owner, define what counts as an agent deployment, publish a small required inventory schema, and open a simple registration route. Collect known agents from cloud, DevOps, data, security, and business automation teams. Add expiration to experiments and assign owners to production use.

In the second month, connect two or three high-value discovery sources, such as cloud identity events, repository searches, and OAuth grants. Create risk lanes and material-change triggers. Pilot the workflow with teams that already operate agents. Their friction points will be more useful than a policy written in isolation.

In the third month, add CI validation for the agent manifest, reconcile observed identities with inventory records, and exercise retirement for one noncritical agent. Report coverage, orphan age, approval lead time, and overdue reviews. Expand discovery only after the reconciliation team can process the leads. More alerts without ownership capacity create a larger blind spot disguised as a dashboard.

Frequently Asked Questions

Is every unsanctioned AI tool a shadow agent?

No. A chat tool that only returns text may be shadow AI, but it is not necessarily an agent. Treat it as an agent when it can pursue a task through tools, workflows, delegated actions, or repeated execution. The governance process can share an intake route while applying different controls.

Who should own the central agent inventory?

One function should operate the inventory and standards, but deployment ownership should remain with the teams that create and use agents. The central operator might sit in security, enterprise architecture, platform engineering, or AI governance. What matters is a clear mandate and integration with identity, DevOps, procurement, privacy, and incident response.

Can cloud logs discover every shadow agent?

No. Logs can reveal identities, API calls, role changes, and unusual automation, but an agent may run locally, use delegated user access, or operate entirely inside a SaaS product. Combine cloud evidence with code, CI/CD, OAuth, browser, vendor, network, and human reporting. Treat every signal as a lead to reconcile.

When should an agent return for approval?

Re-review it when a change can alter impact or exposure, such as a new tool, broader permission, new sensitive data, model or provider change, production deployment, external users, persistent memory, or removal of a human approval step. Routine changes can use delegated approval when policy and regression evidence permit it.

Sources

• OWASP GenAI Security Project: Agentic AI Security Initiative
• OWASP Top 10 for Agentic Applications for 2026
• NIST AI Risk Management Framework
• NIST AI 600-1, Generative AI Profile
• OpenAI: Safety in building agents
• OpenAI: Evaluate agent workflows
• AWS IAM: Refine permissions using last accessed information
• Microsoft Learn: View managed identity update and sign-in activity
• Google Cloud: Security log analytics