TL;DR: Most SOC 2 Type II reports do not verify what you think they verify. SOC 2 Type II verifies specific controls over a defined period, not every security claim a vendor makes. Credential isolation is an architectural property you can verify by asking where tokens live and whether they ever reach the LLM context. Use the verification steps in this article to audit any agent platform before your next enterprise security review.
Enterprise security reviews fail from both sides of the table. Security reviewers accept vague claims about SOC 2 scope, credential isolation, and integration counts at face value, then find gaps they cannot document when a prospect pushes back. Engineering teams fail these reviews not because their product is insecure, but because they cannot prove it with documentation. Whether your team is sending the security questionnaire or answering it, the same three misconceptions drive the most stalls.
We correct three misconceptions that cost enterprise deals. First, SOC 2 Type II verifies specific controls over a defined period, not every security claim a vendor makes. Second, credential isolation is an architectural property, not a policy promise, and you can verify it by asking where tokens live. Third, integration counts require action coverage and auth method detail to be meaningful. We show you how to audit each claim, what Composio's architecture enforces, and give you a set of requirements for your next vendor review.
Why enterprise security reviews often fail
Security reviews impacting deal velocity
Security reviews are now a standard deal stage in B2B SaaS. When a prospect sends a credential handling questionnaire, your team needs documented answers, not adjectives. A stalled security review delays deal velocity and puts NRR at risk when existing customers cannot expand due to compliance gaps.
The problem compounds when you evaluate an agent platform. Your engineering team built fast and stored credentials in the application layer. Now a security reviewer asks pointed questions about credential handling, audit logging, and compliance scope. You cannot respond without either admitting gaps or dedicating a sprint to hardening infrastructure.
Beyond the buzzwords: Reality vs. claims
Marketing language like "enterprise-grade" and "secure by design" carries no verifiable meaning in a security review. A reviewer needs named certifications, architecture documentation, and audit log samples. When a vendor claims "1,000+ integrations" without specifying action coverage or auth methods, that claim is not auditable. When they claim "credentials are secure" without explaining where tokens live or whether they reach the LLM context, that claim is not verifiable.
The gap between marketing copy and architectural reality is where deals stall. Security reviewers know this, so they ask for proof. Vague claims fail reviews because they cannot be verified against a threat model.
How to audit platform security
We use a three-part audit framework: SOC 2 scope verification, credential isolation architecture, and integration count validation. Each section gives you specific questions to ask and verifiable evidence to request. At the end, you will have a set of requirements you can use in your next vendor review, whether you are evaluating a vendor's claims or preparing your own platform to withstand that scrutiny.
What SOC 2 Type II audit reports actually verify
What SOC 2 Type II actually measures
SOC 2 Type II tests the operating effectiveness of controls over a defined period, typically 3 to 12 months. It verifies that controls work as designed, not that every security claim is true.
Type II reports require a minimum three-month observation period to demonstrate operational effectiveness over time. This is different from Type I, which only verifies that controls are designed correctly at a point in time. When a vendor claims SOC 2 Type II compliance, ask what period the report covers and which Trust Services Criteria are in scope.
What SOC 2 compliance actually covers
SOC 2 requires only the security criterion (also known as the common criteria). Many vendors scope only the security criterion, which is legitimate but narrower than what marketing copy often suggests. The other four categories (availability, processing integrity, confidentiality, privacy) are optional and depend on the services the vendor provides.
SOC 2 works as a reporting framework. Each service organization defines its control scope to meet user needs. This means two vendors can both claim SOC 2 Type II compliance while covering different scopes. One might include availability and confidentiality; another might scope only security. You cannot tell from the claim alone.
What remains outside the audit
SOC 2 Type II does not cover agent-specific risks like prompt injection, model behavior, or the security of third-party apps the agent connects to. Prompt injection is a cyberattack that manipulates a large language model into executing an attacker's instructions instead of the system's. The attack exploits a structural property of LLMs: they cannot distinguish instructions from data since both arrive as natural-language text.
The OWASP Top 10 for LLM Applications names ten specific risks in LLM-powered apps, including prompt injection, data leakage, and excessive agency.
Traditional audit logs do not capture agentic decision chains. Agentic decisions move through probabilistic reasoning chains, and those chains do not map cleanly to the "who did what when" records SOCs are built around. This is the misconception that costs buyers: assuming SOC 2 Type II covers agent-specific security when it does not.
Auditing your AI platform security
Ask these questions in your next vendor review:
Trust Services Criteria scope: What categories are in scope? Security is required; the other four are optional. Request the attestation report to confirm.
Audit period: What dates does the report cover? Type II requires a minimum three-month observation period.
Control exclusions: What controls are excluded? Ask specifically about agent-specific risks like prompt injection and model behavior.
Bridge letter: If the report period ended more than three months ago, request a bridge letter confirming controls remain effective.
Full report access: Can you provide the attestation report under NDA, not just a summary page?
Hardening your agent credential security
Credential storage for AI compliance
The architectural question is simple: where do tokens live, who can access them, and do they ever reach the LLM context? Application-layer storage means credentials sit in your database or environment variables, accessible to application code and potentially visible in logs or error traces. Isolated vault storage means credentials are stored separately, encrypted at rest, and resolved only inside an isolated runtime.
Composio stores credentials with AES-256 encryption and isolates them from application code and the LLM context. Connected-account credentials, auth configs, and API keys are encrypted at rest using AES-256-GCM, and all traffic is encrypted in transit using TLS. This is a verifiable architectural property, not a policy promise.
A contained architecture makes authorization decisions outside the model. When you evaluate a vendor, request documentation showing where credential resolution occurs in the request path. The credentials should never appear in LLM prompts, logs, or memory.
Preventing credential cross-pollination
Credential cross-pollination happens when tokens leak between users, teams, or agent instances. In a multi-tenant system, one customer's credentials should never be accessible to another customer's agent. Multi-tenant credential isolation requires scoping each tenant's credentials to its own sandbox and logging every credential use per request.
The isolation mechanism must be architectural, not procedural. Proxy-based credential injection is the strongest approach: credentials are applied at the network layer and never enter the sandbox. The agent calls a tool, the platform verifies identity, evaluates policy, brokers the appropriate access, and centralizes the resulting audit trail. The agent does not need to manage or retain the credential itself.
Monitoring and securing agent activity
A complete audit trail logs every tool call with user, team, tool, action, and outcome, including denied calls. Comprehensive logging is both a security control and a compliance requirement. Capture every authentication attempt (successful and failed) and all authorization decisions with policy evaluation details. Logs must be immutable, encrypted, and retained according to regulatory requirements.
When something goes wrong with an agent, security teams need to reconstruct what it did, why, and with what authority. Traditional audit logs do not capture that. Do not give agents permission to alter or delete their security logs. Send audit events to separate, tamper-resistant storage.
Chain of custody is the compliance standard. An activity summary that only logs successful calls is not usable as compliance evidence. Request a sample audit log showing both successful and denied tool call attempts, including user, team, tool, action, and outcome fields. Verify logs are immutable and time-synchronized.
Must-ask vendor security questions
Use these requirements in your next vendor review:
Credential storage location: Where are credentials stored? Request architecture documentation showing storage location and encryption method.
Encryption at rest and in transit: Are they encrypted at rest and in transit? Verify AES-256 or equivalent for at-rest encryption and TLS for in-transit.
Agent access to raw tokens: Can the agent access raw tokens? The answer should be no. Credentials should be resolved inside an isolated runtime.
Credential enumeration: Who can enumerate credentials? Access should be governed by policy-as-code enforcement, not shared keys.
Team member departure: What happens when a team member departs? Credential enumeration through a centralized vault should be straightforward because all credentials are stored in one governed location.
Sample audit log: Can you provide a sample audit log? Request a log showing denied calls, not just successful ones.
How to audit AI agent integration volumes
How we audit integration usage
Integration counts require three details to be meaningful: action coverage per integration, auth method (OAuth vs. API key), and whether the integration is maintained. A vendor claiming "1,500+ integrations" might mean 1,500 apps with one generic endpoint each, or 1,500 apps with specific actions agents need in production. You cannot tell from the count alone.
Composio maintains a public toolkit catalog where you can browse the apps your agent can act on. For each integration, confirm it exposes multiple, distinct actions. Each toolkit supports different authentication methods such as OAuth, API Key, or Bearer Token. OAuth2 allows you to configure scopes for what data and actions your integration can access. API Key and Bearer Token permissions are typically fixed based on the key's access level.
Security impacts of integration choices
Each integration is a potential attack surface. OAuth-managed integrations with scoped permissions are safer than API keys stored in application code, this is OAuth debt: the maintenance obligation created by each in-house OAuth implementation.
Validating your auth coverage
Ask these questions:
Token refresh handling: Does the platform handle token refresh? Token lifecycle management should be automatic, not a manual engineering task.
Upstream API changes: What happens when an upstream API changes its auth model? A managed platform should handle this without requiring engineering time from your team.
Subprocessor list: Is there a documented subprocessor list? Request this for GDPR compliance and vendor risk assessment.
OAuth scope configuration: Can you configure OAuth scopes per integration? Scope-based access control is a verifiable security property.
Red flag: integrations relying solely on static API keys without scope-based access control or OAuth options.
Proven ways to audit integration stats
Use this verification method:
Public integration catalog: Ask for a public integration catalog. A vendor should maintain a browsable list of supported apps.
Action coverage verification: Check action coverage for the specific tools you need. Do not accept a count; verify the actions your use case requires.
Auth method confirmation: Confirm the auth method for each integration. OAuth with scoped permissions is safer than static API keys.
Maintenance commitment: Ask for a documented maintenance commitment. What happens when an upstream API changes? Who is responsible for updates?
Security review quick guide
Claim type | What to ask | Verifiable evidence |
|---|---|---|
SOC 2 scope | Which Trust Services Criteria are in scope? What period does the report cover? What controls are excluded? | Full attestation report under NDA, bridge letter if report is older than 3 months, documented exclusions |
Credential isolation | Where are credentials stored? Can the agent access raw tokens? Are they encrypted at rest and in transit? | Architecture documentation showing credential flow, encryption method (AES-256 or equivalent), audit log sample |
Integration count | How many actions per integration? What auth methods are supported? Who maintains integrations? | Public integration catalog with action coverage, documented auth methods (OAuth vs. API key), maintenance SLA |
How Composio meets security compliance demands
Composio is an integration platform. The managed auth layer is one part of it, not the whole product. The platform connects agents to 1,500+ apps with specific action coverage, handles credential lifecycle, and generates the audit trail enterprise reviewers ask for.
SOC 2 Type II and ISO 27001 coverage
Composio holds SOC 2 Type II and ISO/IEC 27001:2022 certifications. The Composio Trust Center provides access to the latest SOC 2 Type II report, subprocessor list, and pre-filled compliance packs covering common frameworks and insurance certificates. Composio's SOC 2 Type II certification covers the entire business, not only enterprise-tier accounts or a subset of infrastructure. The documentation is already assembled for enterprise security reviews.
When your next enterprise prospect asks where credentials are stored, Composio's centralized vault with AES-256 encryption and isolation from application code gives you a documented answer. SOC 2 Type II and ISO/IEC 27001:2022 certifications mean that answer holds up in a formal security review.
Credential isolation implementation
Composio stores tokens with AES-256 encryption and isolates them from application code and the LLM context. The agent calls a tool, Composio resolves which connected account to use, decrypts the credential inside an isolated runtime, injects it into the outbound HTTP request, and returns the response. The credential never reaches the model or appears in your application layer. Credentials persist across sessions and refresh automatically. Composio manages the full token lifecycle so your agent doesn't need to re-authenticate between runs or handle expiry logic.
Policy-as-code enforcement evaluates access restrictions in the request path before the model is involved. An admin disables the "delete" action for a Slack integration. The agent cannot delete, regardless of what the prompt says, what the model reasons, or what a user tries to inject. A prompt instruction and a policy-as-code control look identical until a user tries to override one. The prompt bends; the policy does not.
Composio's managed OAuth layer handles the full token lifecycle across 1,500+ connectors, which removes the refresh-cycle complexity that typically consumes senior engineer time during the first weeks of any new integration.
Managing 1,500+ ready-to-use integrations
Composio's catalog includes 1,500+ apps with specific action coverage, not generic endpoints. This is the specific operations agents need in production, spanning GitHub, Slack, Salesforce, Gmail, Jira, and hundreds more. You can browse the full catalog to verify action coverage for the tools your customers request.
Self-built OAuth means self-built audit logging, self-built token lifecycle management, and self-built documentation when a security questionnaire arrives. Composio's 1,500+ pre-built connectors include the managed credential layer and the audit trail that enterprise reviewers ask for, so the security review artifact exists before the question is sent.
Book a call to walk through your security requirements before the next enterprise review. Schedule time with our team to review your specific compliance needs and see how Composio's architecture addresses them.
FAQs
Does SOC 2 Type II cover all security controls?
No. SOC 2 Type II verifies the operating effectiveness of specific controls over a defined period, typically 3 to 12 months. Ask which Trust Services Criteria are in scope and what agent-specific risks (prompt injection, model behavior, third-party app security) are excluded.
Can other users access my agent credentials?
In Composio's architecture, credentials are stored in a centralized vault with AES-256 encryption and are isolated from application code and the LLM context. Access is governed by policy-as-code enforcement, not shared keys.
How do I verify an integration count claim?
Ask for a public integration catalog, check action coverage for the specific tools you need, and confirm the auth method for each integration. A count without action coverage and auth detail is not verifiable.
What documentation should a vendor provide during security review?
A vendor should provide their SOC 2 Type II report with scope details, a bridge letter, architecture documentation showing credential flow, audit log samples, and a subprocessor list. Composio provides these through its trust center.
Key terms glossary
SOC 2 Type II: An audit that tests the operating effectiveness of an organization's controls over a defined period, typically 3 to 12 months, against the Trust Services Criteria.
Trust Services Criteria: The five categories SOC 2 audits evaluate: security, availability, processing integrity, confidentiality, and privacy.
Credential isolation: An architectural property where tokens are stored separately from application code and LLM context, resolved only inside an isolated runtime.
Policy-as-code: Access restrictions defined administratively and evaluated in the request path as code, before the model is involved.
Audit trail: A complete log of every tool call including denied actions, usable as compliance evidence rather than an activity summary.
OAuth debt: The maintenance obligation created by each in-house OAuth implementation, which grows each time an upstream API changes its authentication model.
Integration count: The number of apps a platform connects to, which is only meaningful when paired with action coverage and auth method detail.
Get started
