The sanctioned alternative to shadow AI

TL;DR: Blanket bans on AI tools don't stop shadow AI, they push it underground where credentials go unmanaged and every write action goes unlogged. AI agents that write to systems of record raise the stakes well beyond a user pasting text into a chatbot. The sustainable fix is a sanctioned gateway that isolates credentials with AES-256 encryption, enforces policy controls in the request path before the model acts, and logs every call including denied ones. This playbook shows IT leaders exactly how to build that system.

Shadow AI isn’t a future risk companies can address later. Employees are increasingly turning to AI tools that haven’t gone through IT or security review, often because approved solutions don’t fully meet their needs. But detecting shadow AI is only half the challenge. Simply blocking unapproved tools doesn’t necessarily stop their use. Instead, employees may turn to personal accounts, unapproved API keys, or other workarounds that are even harder for security teams to monitor and control.

A more effective approach is to make the approved path the easiest path. Organizations should provide AI tools that employees genuinely want to use, while embedding the security, governance, and controls needed to use them responsibly.

Why restrictive policies fuel shadow AI growth

Static acceptable use policies target the wrong layer. They describe what employees should do, evaluated after the fact when IT discovers a violation during an audit or after a breach. They don't enforce anything at the moment a tool call is made.

Documenting shadow AI threat vectors

Shadow AI enters organizations through three distinct layers, each carrying a different risk profile:

1. Web-based chatbots: Employees paste sensitive data, customer records, internal source code, or financial projections into consumer LLMs. Samsung's experience is the clearest documented example: within 20 days of allowing ChatGPT access, three separate data leaks occurred, one involving an engineer pasting proprietary equipment yield-optimization code requesting code optimization.

2. Direct API integrations: Developers hardcode API keys to connect models directly to internal databases, CRM systems, or code repositories. These keys sit in local environments, continuous integration and deployment (CI/CD) secrets, or application code with no central inventory, no rotation schedule, and no audit trail.

3. Agent-building within SaaS platforms: Autonomous agents run inside tools your organization already approved, Salesforce, Notion, Slack, without IT having any visibility into what those agents are accessing or writing. The SaaS vendor is sanctioned. The agent running inside it is not.

How restricted access fuels workarounds

When IT blocks an AI tool at the firewall or through a deny list, developers don't stop building. They route around the restriction using tunneling tools that create a public URL for any private service, often without elevated permissions. The tool call still happens, but now it runs through infrastructure you can't monitor, using credentials you didn't provision, with no log of what the agent wrote or read. Blocking drives risk underground rather than eliminating it.

The unique threat of unrestricted AI agents

The difference between a user pasting text into a chatbot and an AI agent running against your systems is architectural, not incremental. While chatbots typically have narrowly scoped, static-permission access to enterprise systems with limited ability to take autonomous action, agents operate with persistent credentials, maintain context across sessions, and execute multi-step workflows without human confirmation at each step.

An agent with write access to Salesforce doesn't just retrieve a lead. It can perform actions like updating records, deleting contacts, or modifying data, often within a single task execution. AI agent security shifts from who accesses data to what AI agents are allowed to do with it, and agents perform those actions without human oversight, often in real time.

Scoping agent permissions to the task

The danger with write-enabled agents is scope creep at the permission layer. An agent provisioned for lead scoring doesn't need delete access to the CRM. An agent generating GitHub pull request summaries doesn't need push access to main. But OAuth scopes granted during initial integration frequently cover far more than the task requires, because scoping precisely takes time the developer doesn't have during a late-night push before a demo.

When a prompt injection attack hits an over-scoped agent, the blast radius is defined entirely by what credentials the agent holds. The OWASP Top 10 for Large Language Model Applications lists prompt injection as the top risk precisely because a hardcoded "don't delete anything" prompt is not an enforcement control. A prompt instruction is a sign on a door. Policy-as-code evaluated in the request path is the lock.

Mitigating risks of hardcoded API keys

Hardcoded API keys are not just a developer hygiene problem. They're a structural problem created when integration architectures require developers to manage credentials directly. When the integration layer puts raw token management on the developer, some fraction of those tokens will end up in application code, in environment files committed to version control, or in Slack messages asking a colleague for help debugging an OAuth error.

Every tool call routes through a server-side execution layer where the gateway resolves the credential from an AES-256 encrypted vault, injects it into the outbound request, and returns the response. The developer's code and the model never touch the raw token. This is not a configuration option, it is how the system works.

Mapping shadow AI to MCP vulnerability

The Model Context Protocol (MCP) is becoming a standard interface for connecting AI models to external tools, and adoption is moving faster than governance frameworks can keep pace. MCP simplifies how agents connect to data sources, but that simplification also concentrates credential risk. A single breached MCP server deployed without authentication controls gives attackers access to every integrated database, file system, and cloud service connected to that agent, because MCP servers aggregate credentials for multiple enterprise services by design.

Enforcing least privilege in AI workflows

The governance question is not whether your organization will use AI agents. It is whether those agents will run against your systems with credentials your IT team controls, through a policy layer your admins configure, with a log your auditors can read. The table below shows what that distinction means in practice.

Enforcing access at the request layer

Least privilege for AI agents means the agent's permission scope matches the minimum required for the specific task, evaluated per action rather than granted once at connection time. An agent that reads a Salesforce contact list should not hold the credential scope to delete records. That restriction needs to live in the request path, not in a prompt instruction the model can reason around.

Composio's policy-as-code enforcement evaluates access restrictions in the request path before any model interaction. An admin's decision to block delete actions holds regardless of what the model is instructed to do, because the enforcement happens at the gateway, not inside the prompt.

Mandatory controls for sanctioned AI usage

Moving from shadow AI exposure to a sanctioned architecture requires four specific technical controls. These are not optional features, they are the minimum bar for an architecture that will hold up in a security review.

Encrypting credentials at the source

AES-256 encryption at rest is the baseline. What matters architecturally is where the decryption happens. If the credential is decrypted inside your application layer before the API call is made, it enters the application's memory space and potentially the model's context. If decryption happens inside an isolated execution runtime after the policy check passes, the raw token never reaches your code or the model.

Blocking shadow AI at the API level

Runtime enforcement evaluates every tool call against the policy before the call reaches the target API. This is the characteristic that makes the sanctioned gateway meaningfully different from a static acceptable use policy, which only describes intent without enforcing it.

Complete audit trail including denied calls

Denied calls are the most important entries in any audit trail. They prove the control worked. They surface attack attempts, misconfigurations, and policy gaps that successful calls cannot reveal. When an enterprise prospect's security team asks "how do you know your governance controls are working?", the answer is a log showing what was blocked, when, for whom, and why, not a description of what your policy document says. Composio logs every tool call with user, team, tool, action, and outcome, with denied calls included.

Replacing blanket bans with granular controls

The transition from restriction to governance is a phased process, not a single policy change. Here is a step-by-step path that preserves engineering velocity while putting infrastructure-layer controls in place.

Prioritize use cases by risk impact

Not all AI agent use cases carry the same risk. Start by categorizing what is already running:

• Read-only, internal data: Lowest risk. An agent that reads internal documentation and surfaces summaries carries minimal write exposure. Approve with logging.

• Read, external data: Moderate risk. An agent reading customer-facing CRM data requires audit logging and identity propagation to distinguish which end user triggered the read.

• Write, internal systems: High risk. Any agent with write access to code repositories, databases, or ticketing systems requires policy-as-code enforcement at the action level before approval.

• Write, customer-facing systems: Highest risk. These agents need credential isolation, per-action scope enforcement, denied-call logging, and compliance certification verification from the gateway layer before they touch production.

Transition to authorized AI architectures

The build-vs-buy question for AI gateways comes down to ongoing engineering cost, not just initial build effort. Every OAuth implementation your team builds in-house creates a maintenance obligation that triggers every time an upstream API changes its authentication model. When a token expires overnight and nobody refreshes it, the Monday morning pipeline report simply stops working.

The 11x case study documents what this looks like in practice: deploying Composio for Outlook, Salesforce, Calendly, and People Data Labs integrations saved approximately 380 engineering hours while enabling $4.2M in enterprise deals. The integration backlog that consumed senior engineer time became a configuration task.

Set granular enforcement windows per team

Roll out controls by team and environment, not organization-wide on day one. Start with the highest-risk teams, those with write access to production systems or customer data, and establish the policy-as-code baseline there first. Expand to lower-risk teams once the enforcement pattern is confirmed working. This approach lets you catch configuration gaps before they affect the full organization.

Prioritize output over access controls

Monitoring what agents produce, not just what they access, surfaces a category of risk that access controls alone miss. An agent with correctly scoped read-only access to a customer database can still produce a summarized output that effectively leaks personally identifiable information (PII) if the output isn't inspected before delivery. Pair access enforcement with output review for any agent operating on regulated data, and build that review step into the agent's task flow rather than treating it as a separate IT function.

Essential shadow AI governance frameworks

Sanctioned architecture only pays off if you can prove it's working. That proof comes from three places.

Using audit trails to identify unsanctioned access attempts

Audit logs from the managed gateway serve a secondary function beyond compliance documentation: they can surface integration attempts that didn't go through IT. When you see a tool call for a service your team hasn't approved, that may signal a developer tried to connect something outside the governed path. The MCP server listing API gives admins a complete inventory of every MCP server registered in the environment.

Audit evidence for security compliance

The security questionnaire questions come every time you enter an enterprise deal cycle. Having pre-filled, verified answers reduces response time from days to hours and signals operational maturity to the buyer's security team.

Security questionnaire cheat sheet:

• Question: How are third-party API credentials stored and secured?

  • Answer: Composio encrypts credentials using AES-256 at rest and isolates them within a dedicated runtime environment, ensuring they are never exposed to the LLM context or application code.

• Question: What compliance certifications does the integration layer hold?

  • Answer: Composio holds SOC 2 Type II and ISO/IEC 27001:2022 certifications.

• Question: How are access permissions enforced?

  • Answer: Composio enforces permissions via policy-as-code in the request path, blocking unauthorized actions before they reach the target API.

Composio holds both SOC 2 Type II and ISO/IEC 27001:2022 certifications with pre-filled compliance packs, covering common framework requirements so your team doesn't start from a blank document. Most enterprise security questionnaires return within a day.

Architectural isolation of API credentials

When credentials are managed in-house, every upstream API change lands on your engineering calendar. Composio's managed OAuth layer absorbs that maintenance obligation, handling token refresh automatically so an agent doesn't fail at 3 AM because a token expired and nobody was awake to refresh it. The swap happens inside the vault layer before the agent's call ever reaches the external API.

Managing permissions via admin console

IT administrators manage, review, and revoke permissions centrally through the Composio dashboard without redeploying code. An admin disabling the "delete" action for the Salesforce integration for the RevOps team restricts every agent and every framework calling that integration, because the enforcement happens in the request path at the gateway, not inside the agent's code.

When a team member departs, credential enumeration is straightforward: all credentials are in one governed vault rather than distributed across developer machines, CI/CD secrets, and third-party SaaS accounts. Offboarding is a single revocation, not a multi-system scavenger hunt.

Shadow AI governance checklist:

• Inventory all active AI tool connections across developer, product, and operations teams

• Classify each use case by write-access risk (read-only, write-internal, write-customer-facing)

• Route all production agent tool calls through a managed gateway with AES-256 credential isolation

• Configure policy-as-code rules blocking destructive actions (delete, export, bulk-modify) per team role

• Verify audit logging captures denied calls, not just successful ones

• Confirm MCP server instances are inventoried and access-controlled, not publicly addressable

• Obtain SOC 2 Type II and ISO/IEC 27001:2022 attestation documents from your integration vendor

• Set credential rotation schedules and confirm automated refresh is active for all OAuth connections

• Test offboarding: revoke one connected account and confirm the agent can't complete a tool call

• Export an audit log sample and verify it meets your compliance auditor's evidence requirements

Credential governance as the foundation of a complete execution layer

Credential isolation, policy enforcement, and audit logging answer the question of whether an agent is authorized to act. They do not answer what the agent does after that authorization passes.

The gap that causes production failures is not usually a credential breach. It is an agent that reaches a valid authorization decision, then encounters a rate-limited API, a malformed response, or a mid-task dependency failure, with no retry logic, no sandboxed fallback, and no mechanism to verify whether the action actually completed. A governance framework that secures credentials but leaves execution unmanaged produces a different category of failure: the agent was authorized to act, acted, and nobody can confirm the outcome.

Composio's role in that execution path extends beyond the vault and the policy check. Authorized tool calls route through an execution layer that handles retries on transient failures, sandboxes destructive actions before they reach production, and returns structured outcome verification rather than a raw API response. The agent receives confirmation that the action completed, not just confirmation that the request was sent. That distinction matters for any workflow where an incomplete action, a CRM record half-updated, a file partially written, is operationally worse than no action at all.

The self-learning dimension compounds over time. Each verified outcome feeds back into the routing layer, so the execution path for a given action type improves based on what has succeeded and failed across prior calls. This is not prompt tuning. It is the execution infrastructure accumulating a track record at the action level, which is what separates an agent that degrades under production load from one that improves accuracy as it operates.

The credential governance controls described in this playbook are the authorization layer of that architecture. They are a prerequisite, not the complete system. An IT team that deploys credential isolation and policy-as-code enforcement without a governed execution layer has secured the front door and left the rest of the building unmonitored. The average cost of a data breach reached $4.88 million in 2024, a 10% year-over-year increase and the highest figure ever recorded, according to the IBM Cost of a Data Breach Report 2024. The risk of letting shadow AI continue unaddressed is not theoretical. The risk of a blanket ban is also real: it makes your organization's AI posture invisible, not absent.

The path that addresses both is a sanctioned gateway that gives developers what they need, isolates credentials from the code and the model, enforces policy at the infrastructure layer, and logs everything. That architecture exists today. Building it from scratch is months of engineering time you can measure directly. Buying a managed layer that already holds the certifications your next enterprise prospect will ask for is the decision that lets your team ship rather than maintain.

Book a call to walk through your security requirements before the next enterprise review.

FAQs

How does Composio secure API credentials from the LLM?

Composio stores credentials with AES-256 encryption, isolated from the calling application and the LLM context, and resolves them inside an isolated runtime at execution time, so the raw token is injected directly into the outbound HTTP request and the LLM context never contains it. The credential is isolated from both application code and the model by architecture, not by configuration.

Can we restrict specific actions within an approved integration?

Yes, administrators configure policy-as-code rules through the Composio dashboard to block specific actions, such as deleting records or exporting data in bulk, and those restrictions are evaluated in the request path before the tool call reaches the target API.

What compliance certifications does Composio hold?

Composio holds SOC 2 Type II and ISO/IEC 27001:2022 certifications.

Does Composio detect shadow AI usage on the network?

Composio provides the sanctioned execution destination for AI agent tool calls, not network scanning or shadow IT discovery. Organizations use separate detection tools to identify unsanctioned usage, then route approved workflows through our managed gateway to enforce credential isolation and policy-as-code controls.

Does policy-as-code enforcement require redeployment when a policy changes?

Policy changes made through the Composio admin dashboard apply across connected agents and frameworks calling that integration, because enforcement lives in the gateway request path rather than in agent code. Administrators manage, review, and revoke permissions centrally without touching a deployment pipeline.

Key terms glossary

Policy-as-code: An approach to security management where access policies are defined, updated, and enforced via code rather than manual processes or prompt instructions, evaluated in the request path before the tool call reaches the target API.

Credential isolation: An architectural security control that prevents application code or language models from directly accessing or exposing raw API keys and tokens, implemented by resolving credentials inside an isolated runtime and injecting them into outbound requests.

Model Context Protocol (MCP): A specification that enables developers to build standardized connections between AI models and external data sources or tools, creating a consistent interface that also centralizes credential and permission risk when left unmanaged.

Least privilege: The access control principle that every agent, user, or service account holds only the minimum permissions required for its specific task, applied at the action level rather than the application level for AI agent governance.

Audit trail: A complete, immutable record of tool call events including user, team, tool, action, and outcome with denied calls included, that serves as chain-of-custody evidence for compliance audits rather than a summary of successful activity.