Vendor Credential Isolation: Why AI Agents Must Never Share API Keys Across Tenants

In mid-2024, a security researcher analyzing a prominent AI automation platform discovered that all customer tenants' agents were making LLM API calls using a single shared API key owned by the platform vendor. The key belonged to the vendor's own Anthropic account. The implications were severe: every prompt sent by any customer's agent was transmitted under the vendor's account, making all customer data visible in the vendor's LLM usage logs. Any data exfiltration from the LLM provider's systems would expose all customers' confidential information indistinguishably. Rate limits were shared across all customers — one customer's burst usage could throttle another's agents. And if the shared key were compromised, every customer's agent would lose LLM access simultaneously.

This is not an isolated case. Audit of popular AI agent platforms in 2025 found that 34% of multi-tenant platforms used shared API keys for at least one LLM provider, with the justification ranging from "it's simpler to manage" to "per-tenant keys are too expensive" to simply "we hadn't thought about it."

Shared API keys across tenants in multi-tenant AI agent platforms represent a fundamental failure of the isolation contract that enterprise customers expect and that data protection regulations require. This guide explains why credential isolation is non-negotiable, what attack vectors shared credentials enable, how to architect proper per-tenant credential isolation, and what BYOC (Bring Your Own Credentials) architectures look like in production.

TL;DR

• Shared API keys across tenants violate data isolation at the LLM provider layer — every prompt from every tenant flows through the same account, with the same usage logs, the same rate limits, and the same compromise blast radius.
• Credential leakage attack vectors in shared-credential environments are numerous: timing side-channels that correlate rate limit exhaustion to competing tenants' activity, provider-side logs accessible to vendor employees, and single-credential compromise that affects all tenants simultaneously.
• Per-tenant credential vaults (one vault namespace or account per tenant) provide cryptographic isolation that makes cross-tenant access technically impossible, not just policy-prohibited.
• Blast radius analysis: shared credentials mean a single compromise affects N tenants simultaneously; per-tenant credentials mean any compromise affects exactly 1 tenant.
• BYOC (Bring Your Own Credentials) architectures allow enterprise customers to use their own LLM provider accounts, eliminating the vendor's ability to access customer data at the provider layer.
• Armalo's trust scoring explicitly evaluates credential isolation in multi-tenant deployments — agents sharing credentials across tenants receive critical security dimension deductions.

The Multi-Tenancy Isolation Contract

Enterprise customers adopting multi-tenant AI agent platforms operate under an implicit isolation contract: their data, their configurations, their agent behaviors, and their costs are isolated from other tenants. This contract is what makes multi-tenant SaaS viable for enterprise customers — they accept the operational efficiency of a shared platform in exchange for contractual and technical isolation guarantees.

Credential sharing violates this contract at the most fundamental level. When Tenant A's agent and Tenant B's agent use the same API key to call the same LLM provider:

Data isolation fails: Both tenants' prompts appear in the same API usage log. The vendor (or anyone with access to the vendor's provider account) can read both tenants' prompts. If the LLM provider experiences a breach, all tenants' data is in the same breach scope.

Performance isolation fails: API rate limits are per-key. Tenant A's burst usage reduces the available rate for Tenant B's agents. Tenant B's latency and throughput are directly affected by Tenant A's behavior — a guarantee violation that's almost impossible to debug from Tenant B's perspective.

Cost isolation fails: Shared keys mean shared billing. If Tenant A's agent has a runaway cost issue (infinite retry loop, prompt injection that causes massive output generation), the cost spike appears on the vendor's shared account and may affect all tenants through rate throttling or account suspension.

Compliance isolation fails: Many regulated industries require that data processing occurs in logically isolated environments. A SOC 2-certified multi-tenant platform using shared LLM API keys may not satisfy the customer's data processing addendum (DPA) even though the platform itself is certified — the certification doesn't cover the LLM provider layer if the keys are shared.

Attack Vectors Enabled by Shared Credentials

Vector 1: Prompt Data Cross-Contamination via Provider Logs

LLM providers maintain usage logs for billing, abuse detection, and support. These logs contain prompt contents, at least in hashed or truncated form, and sometimes in full for debugging purposes. For a vendor using a shared API key, all customers' prompt data flows through the same log records.

An attacker who gains access to the vendor's LLM provider account (via credential compromise, insider threat, or social engineering at the provider) has access to all customers' prompt data in a single breach. With per-tenant credentials, the same attacker gains access to exactly one customer's data.

The threat model isn't just external attackers. Internal threats — a disgruntled employee, an authorized researcher who exceeds their data access scope — are equally dangerous. Per-tenant credentials ensure that employees' access to one customer's LLM logs cannot be extended to all customers' logs.

Vector 2: Rate Limit Exhaustion as a Denial-of-Service Vector

Tenant A, operating in the same multi-tenant platform as Tenant B, deliberately or accidentally sends a massive burst of LLM requests. The shared API key hits its rate limit. All of Tenant B's agents receive 429 (Too Many Requests) responses simultaneously, even though Tenant B's usage is entirely within normal bounds.

This is a denial-of-service attack that doesn't require any access to Tenant B's systems — it only requires the ability to generate LLM requests under the same shared credential.

For platforms serving competing enterprises, the attack becomes intentional: a malicious customer could deliberately exhaust the shared credential's rate limits precisely when a competitor's critical workload is running.

Vector 3: Model Version and Configuration Poisoning

Many LLM providers allow per-account configuration of default model versions, safety filters, and output settings. If a malicious tenant can influence these account-level settings (through a support request, an account configuration API if the vendor exposes one, or by exploiting a misconfiguration in the platform's API key permission scope), all tenants using the shared credential are affected.

Per-tenant credentials eliminate this vector entirely — each tenant's LLM configuration is isolated to their own account.

Vector 4: Cost Attribution Manipulation

In shared-credential environments, the platform vendor must track which tenant generated which API calls for billing purposes. This tracking is typically done by correlating platform-side logs with API usage logs — an imprecise process that's vulnerable to manipulation.

If a malicious tenant can trigger API calls that are attributed to another tenant's cost meter (through timing attacks, session confusion, or race conditions in the attribution logic), they can artificially inflate another tenant's bill or avoid their own costs.

Per-tenant credentials make attribution trivially accurate: usage under Tenant A's key is Tenant A's usage, period. No attribution logic required.

Vector 5: Single-Key Compromise Cascading Failure

If the shared API key is compromised — via credential theft, insider exfiltration, or accidental exposure in logs — all tenants' agents simultaneously lose access (when the key is revoked as part of incident response) or are all potentially exposed to adversarial manipulation (while the key is compromised).

A compromised shared key affecting 1,000 tenants simultaneously is a P0 incident with maximum blast radius. A compromised per-tenant key affecting 1 tenant is a manageable incident. The architectural choice between shared and per-tenant credentials is the choice between those two incident scenarios.

Per-Tenant Credential Vault Architecture

True credential isolation requires that each tenant's credentials are stored in cryptographically isolated storage that cannot be accessed by other tenants — even in the event of a platform-layer compromise.

Architecture Option 1: Dedicated Vault Namespace per Tenant

HashiCorp Vault Enterprise supports namespace isolation: each tenant gets their own Vault namespace with completely independent policies, secret stores, and audit logs. An agent in Tenant A's namespace literally cannot reference a path in Tenant B's namespace — the namespace boundary is enforced at the Vault API layer.

# Create isolated namespace for each tenant
resource "vault_namespace" "tenant_namespace" {
  path = "tenants/${var.tenant_id}"
}

# Within tenant namespace: LLM credentials
resource "vault_kv_secret_v2" "llm_credentials" {
  namespace = vault_namespace.tenant_namespace.path
  mount     = "secret"
  name      = "llm-providers/anthropic"
  
  data_json = jsonencode({
    api_key = var.tenant_anthropic_api_key
  })
}

# Agent policy: only access own namespace
resource "vault_policy" "agent_policy" {
  namespace = vault_namespace.tenant_namespace.path
  name      = "agent-access"
  
  policy = <<EOT
path "secret/data/llm-providers/*" {
  capabilities = ["read"]
}
EOT
}

Agent authentication tokens scoped to the tenant namespace cannot access any path outside that namespace. The isolation is cryptographic, not just policy-based.

Architecture Option 2: Separate AWS Accounts per Tenant (Enterprise Scale)

For enterprise customers with the highest isolation requirements, separate AWS accounts per tenant provide complete credential isolation: different AWS account IDs, different IAM namespaces, different CloudTrail trails, different billing accounts.

This is the architecture used by AWS Control Tower and AWS Organizations for enterprise multi-tenancy. It's operationally intensive (account provisioning takes minutes to hours) but provides the highest possible isolation guarantee.

Cost: AWS charges $0 for additional accounts (no per-account fee for Control Tower accounts), but the operational overhead of managing hundreds or thousands of accounts requires automation (AWS Account Factory).

Architecture Option 3: AWS Secrets Manager with Per-Tenant IAM Policies

The most common practical architecture for AWS-native platforms: all tenant credentials are stored in the same AWS Secrets Manager service, but strict IAM policy isolation ensures each tenant's agents can only access their own secrets.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::123456789012:role/agent-role"},
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:*:123456789012:secret:tenants/*",
      "Condition": {
        "StringEquals": {
          "secretsmanager:ResourceTag/TenantId": "${aws:PrincipalTag/TenantId}"
        }
      }
    }
  ]
}

This policy uses attribute-based access control (ABAC) to ensure that an agent's IAM role (tagged with its TenantId) can only access secrets tagged with the same TenantId. A bug in the application layer that causes an agent to request another tenant's credentials will be rejected at the IAM level — application-layer bugs cannot cause cross-tenant credential access.

Critical: the TenantId tag on the agent's IAM role must be set by the platform's trusted provisioning infrastructure, not by the agent itself. If agents can modify their own IAM tags, the isolation is broken.

BYOC (Bring Your Own Credentials) Architecture

BYOC is the highest-trust credential isolation model: customers use their own LLM provider accounts, database accounts, and third-party service accounts. The platform vendor never has access to customer credentials.

BYOC Benefits for Enterprise Customers

Complete data isolation: All LLM calls go through the customer's own provider account. The platform vendor has zero visibility into the contents of LLM prompts.

Compliance ownership: The customer maintains direct control of their data processing agreements with LLM providers. They don't need to rely on the platform vendor's DPA with the providers.

Cost transparency: The customer pays LLM providers directly. No intermediation, no markup, complete cost visibility.

No rate limit interference: The customer's LLM quota is dedicated entirely to their use.

Security control: The customer manages credential rotation, access policies, and usage monitoring directly.

BYOC Technical Implementation

The BYOC architecture requires the platform to accept customer credentials at runtime rather than using pre-configured vendor credentials:

interface BYOCCredentialConfig {
  tenantId: string;
  providerCredentials: {
    anthropic?: {
      apiKey: string;        // Customer's own Anthropic API key
      organizationId?: string;
    };
    openai?: {
      apiKey: string;
      organizationId?: string;
    };
    awsBedrock?: {
      roleArn: string;       // Customer's IAM role with Bedrock access
      externalId: string;    // For cross-account trust
    };
  };
  databaseCredentials?: {
    // Customer's own database connection strings
    // Encrypted with customer's own KMS key
  };
}

For BYOC credentials that the customer inputs via a UI or API:

1. Customer enters credentials in a secure input form
2. Credentials are encrypted client-side using the customer's public key before transmission (or encrypted server-side with a customer-specific KMS key)
3. Encrypted credentials are stored in the platform's credential vault
4. Agents retrieve and decrypt credentials using the customer-specific key at runtime
5. Platform vendor employees' access to the vault does not expose credential values (they can't decrypt without the customer's key)

AWS AssumeRole BYOC Pattern

For AWS-based services, the most secure BYOC pattern avoids transmitting credentials entirely. Instead, the customer creates an IAM role in their own AWS account and trusts the platform's AWS account:

// Customer's IAM role trust policy (in customer's AWS account)
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::PLATFORM_ACCOUNT_ID:root"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {
        "sts:ExternalId": "CUSTOMER_SPECIFIC_EXTERNAL_ID"
      }
    }
  }]
}

The platform's agents assume this customer-specific role when performing operations for the customer. The customer's credentials never leave their AWS account — the platform only receives short-lived STS credentials that expire automatically.

Blast Radius Analysis

The security investment case for per-tenant credentials rests on blast radius reduction:

Shared Credentials Blast Radius

Compromise scenario: Platform's shared LLM API key is exfiltrated in a breach.

Blast radius: All N tenants simultaneously lose the confidentiality guarantee for any prompts sent after the compromise date and before detection. All N tenants' agents potentially continue operating under the attacker's control during the window between compromise and detection. Single revocation required, but affects all N tenants simultaneously.

Detection difficulty: A single compromised key makes it impossible to distinguish attacker usage from legitimate tenant usage without per-tenant attribution metadata — which may or may not be maintained.

Recovery time: Issuing a new shared key requires updating all agents that use the key. With 1,000 agents using the shared key, rolling out the new key takes hours.

Per-Tenant Credentials Blast Radius

Compromise scenario: One tenant's LLM API key is exfiltrated.

Blast radius: Exactly 1 tenant is affected. Other tenants are unaffected. Revocation affects exactly 1 key, 1 tenant, 1 set of agents.

Detection: Anomalous usage under the compromised key is attributable to the specific tenant, making incident scope determination immediate.

Recovery time: Issuing a new key for 1 tenant takes minutes.

The blast radius of the worst-case scenario shrinks from N tenants (shared) to 1 tenant (per-tenant) — exactly the isolation contract that enterprise customers require and that data protection regulations mandate.

How Armalo Enforces Credential Isolation

Armalo's behavioral pact system requires agents to declare their credential isolation architecture. A registered agent's pact must include:

• Whether the agent uses shared or per-tenant credentials for each external service
• For shared credentials: justification and mitigating controls
• For per-tenant credentials: the isolation mechanism (vault namespace, separate account, BYOC)

Armalo's adversarial evaluation includes explicit cross-tenant credential isolation testing: deploying two test tenants in the same platform and verifying that the agents' credentials are genuinely isolated at the storage, access, and audit layers. Any platform where test tenant A's agents can access test tenant B's credential vault receives an immediate critical security finding.

The trust oracle's credential isolation score is one of the heaviest-weighted factors in the security dimension (8% of composite score). Platforms where agents share credentials across tenants receive a score that reflects their actual security posture — and that score is publicly queryable by prospective enterprise customers considering deployment.

This market mechanism creates strong incentives for proper credential isolation: platforms with poor isolation scores lose competitive advantage in enterprise sales compared to platforms with verified per-tenant isolation.

Credential Isolation Testing: How to Verify Your Platform Is Actually Isolated

Claiming per-tenant credential isolation is easy. Verifying it is harder. Enterprise customers conducting vendor due diligence should run these tests before signing any enterprise agreement with a multi-tenant AI agent platform.

Test 1: The Cross-Tenant Credential Enumeration Test

Create two test tenants on the platform. From Tenant A's context, attempt to enumerate or access any credentials associated with Tenant B. A properly isolated platform should return either an empty result or a 403 error for any cross-tenant credential lookup.

What to test:

• API calls to the platform's credential management endpoints from Tenant A's auth token, attempting to list or read Tenant B's credentials
• Any administrative API endpoints that might bypass tenant scoping
• Credential metadata endpoints that might reveal the existence or structure of other tenants' credentials

Expected result: Any attempt to access cross-tenant credentials should return either empty results or 403 errors. Any non-empty result from a cross-tenant query is a critical isolation failure.

Test 2: The Rate Limit Attribution Test

Send a burst of API calls from Tenant A that exhausts the rate limits for the shared LLM provider key (if shared credentials are used). Immediately check whether Tenant B's agents experience rate limiting.

Expected result (correct behavior): Tenant B's agents are unaffected by Tenant A's rate limit exhaustion. Each tenant has independent rate limit pools because each tenant uses independent credentials.

Failure mode (shared credentials): Tenant B's agents experience rate limiting after Tenant A's burst — proving that rate limits are shared because credentials are shared.

Test 3: The Usage Log Attribution Test

Send 10 API calls from Tenant A and 10 API calls from Tenant B. Access the LLM provider's usage logs through the platform's UI or API. Verify that:

• Tenant A's logs show exactly Tenant A's 10 calls, attributed to Tenant A's credentials
• Tenant B's logs show exactly Tenant B's 10 calls, attributed to Tenant B's credentials
• Neither tenant can see the other tenant's calls

Failure mode (shared credentials): The platform's usage log UI shows all calls attributed to the same account, with tenant attribution only added as a metadata field by the platform layer — meaning the actual provider logs have no tenant separation.

Test 4: The Vault Access Scope Test

If the platform uses HashiCorp Vault or a similar vault system, request an audit of the vault policy attached to the agent service account used for your tenant. Verify that:

• The vault policy only grants read access to your tenant's secret paths
• The policy does not include wildcards that could grant access to other tenants' paths
• The policy does not grant list access to parent paths that would reveal other tenants' secret names

What the policy should look like:

# Correct: tenant-scoped policy
path "secret/data/tenants/your-tenant-id/*" {
  capabilities = ["read"]
}

# Incorrect: overly broad policy (avoid)
path "secret/data/tenants/*" {
  capabilities = ["read"]  // Allows reading any tenant's secrets
}

Test 5: The Credential Rotation Independence Test

Request a credential rotation for Tenant A's LLM API key. Verify that during the rotation window, Tenant B's agents continue operating without any disruption. This confirms that the credentials are truly independent — rotating one tenant's credential has zero effect on another tenant's operations.

Regulatory and Legal Implications of Credential Sharing

Credential sharing across tenants is not just a security failure — it has direct regulatory and legal implications for enterprise customers operating in regulated industries.

GDPR and Data Protection Regulations

Under GDPR (and equivalent regulations in other jurisdictions), personal data must be processed under appropriate technical and organizational measures. When an AI agent processes personal data (customer names, contact information, financial data) by sending it to an LLM API, the prompt transmission happens under the API credentials.

If those credentials are shared across tenants, the data controller (your organization) cannot demonstrate that the personal data was processed in technical isolation from other controllers' data. This creates a potential GDPR Article 32 compliance gap (technical measures for data security) and may require disclosure in your privacy impact assessments.

GDPR auditors asking "how do you ensure that personal data processed by AI agents is isolated from other organizations' data?" expect a technical answer, not a policy answer. "Our vendor's policy prohibits cross-tenant access" is insufficient. "Our vendor uses per-tenant credentials with cryptographic isolation verified in our penetration test" is sufficient.

SOC 2 Type II Implications

Organizations seeking SOC 2 Type II certification must demonstrate effective controls over third-party service providers. If a vendor's AI agent platform uses shared credentials, the vendor's SOC 2 report should note this as a risk. More importantly, the customer's own SOC 2 controls may reference the vendor's controls — if the vendor's controls are insufficient on credential isolation, it creates gaps in the customer's control environment.

SOC 2 auditors examining AI agent deployments in 2025+ are increasingly asking specifically about LLM provider credential isolation. Organizations that have verified per-tenant isolation can document it clearly. Organizations using shared credentials face explanatory work with their auditors.

Financial Services Regulatory Requirements

For financial services firms regulated by OCC, Fed, or SEC, third-party risk management requirements require vendor due diligence that includes security architecture review. A shared-credential architecture on a vendor's AI platform would typically be flagged as a finding in a formal vendor risk assessment — requiring either vendor remediation before contract signing or a documented risk acceptance.

OCC Bulletin 2013-29 (Third-Party Relationships) explicitly requires covered institutions to assess vendors' security controls, including data segregation. Shared credentials fail any serious application of this standard to AI agent platforms.

Implementing Per-Tenant Credential Isolation: A Migration Guide

For organizations already deployed on a shared-credential platform who need to migrate to isolated credentials, the migration path depends on the platform's architecture and flexibility.

Migration Option 1: Platform-Side Per-Tenant Vaulting

The least disruptive migration: negotiate with the platform vendor to provision per-tenant vault namespaces and migrate your credentials to your own namespace. This requires no changes to your configuration but does require the vendor to actually implement per-tenant vaulting — which many currently don't offer.

Questions to ask your vendor:

• Can you provision a dedicated vault namespace for our tenant?
• Will you provide documentation of the vault policies governing access to our namespace?
• Can we verify these policies in a penetration test?
• What is the migration timeline from shared to per-tenant credentials?

Migration Option 2: BYOC Migration

If the platform supports BYOC, migrate all your agent credentials to BYOC. This requires:

1. Provisioning your own LLM provider accounts (or using existing enterprise accounts)
2. Creating per-environment API keys under your accounts
3. Storing those keys in your own vault (HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault)
4. Configuring the platform to use your credentials instead of its shared pool
5. Verifying that the platform's agents actually use your credentials (not still defaulting to shared)

The verification step is critical — some BYOC implementations are "BYOC in name only" and still route through platform credentials for certain operations.

Migration Option 3: Platform Change

If the current vendor cannot provide credible per-tenant isolation, evaluate alternative platforms that do. The switching costs are real but bounded — agent configurations, workflow definitions, and integration code need migration. This cost should be weighed against the ongoing security and compliance risk of operating on a shared-credential platform.

The evaluation criteria for alternative platforms should include credential isolation as a required capability, not a nice-to-have. Any platform that can't demonstrate cryptographic per-tenant isolation in a technical review should be disqualified from the evaluation regardless of other capabilities.

Monitoring and Detecting Cross-Tenant Credential Leakage

Even with proper credential isolation architecture in place, continuous monitoring is necessary to detect configuration drift, code changes that inadvertently break isolation, or insider threats that deliberately bypass isolation controls.

Automated Isolation Verification

Implement automated isolation verification as part of the CI/CD pipeline and as a continuous production monitoring check:

Vault policy audit job: A scheduled job (daily) that reads all vault policies for all tenant namespaces and verifies they don't contain cross-namespace wildcards or overly broad path patterns. Any policy change that would grant cross-tenant access triggers an immediate alert.

Cross-tenant API call detection: Log every LLM API call with the tenant that authorized it (via the credential used). A query that finds any request where the credential owner doesn't match the request's tenant context indicates isolation breakage.

Rate limit attribution monitoring: If tenants share rate limits (which would indicate shared credentials), rate limit exhaustion in one tenant will correlate with rate limit errors in other tenants. Monitor for this correlation as an isolation failure signal.

def detect_shared_rate_limits(tenant_a_id: str, tenant_b_id: str, window_mins: int = 60) -> bool:
    """
    Returns True if the two tenants appear to share rate limits.
    This is a signal that they may be sharing credentials.
    """
    a_exhaustion_times = get_rate_limit_exhaustion_timestamps(tenant_a_id, window_mins)
    b_request_failure_times = get_request_failure_timestamps(tenant_b_id, window_mins)
    
    for exhaustion_time in a_exhaustion_times:
        # If tenant B had failures within 5 seconds of tenant A's exhaustion, they likely share limits
        correlated_failures = [
            t for t in b_request_failure_times
            if abs(t - exhaustion_time) < 5  # 5 second correlation window
        ]
        if correlated_failures:
            return True  # Likely shared credentials
    
    return False

Insider Threat Detection for Credential Isolation Bypass

The most difficult isolation bypass to detect: a platform employee with vault admin access reads one tenant's credentials and uses them for another tenant's benefit (corporate espionage, market intelligence gathering, or competitive harm).

Detection controls:

• Vault audit log monitoring: Every vault read by a human operator should generate an alert. Human reads of tenant secrets should require incident ticket justification.
• Four-eyes principle for vault access: Any human access to tenant credentials requires a second person to approve and witness. This is standard practice for certificate authorities and should be standard for tenant credential stores.
• Honey tokens: Plant fake credentials in a subset of tenant vault paths. These honey tokens look real but are invalid. If they're ever used (or even tested), it proves unauthorized access — no legitimate workflow should access the honey path.

Pricing the Security Investment in Credential Isolation

Per-tenant credential isolation is not free. Each tenant requires its own vault namespace, its own IAM configuration, and its own audit log stream. The operational overhead scales with tenant count. Security teams proposing credential isolation investment need to quantify the cost and compare it against the risk reduction.

Cost Components

Vault infrastructure overhead: HashiCorp Vault Enterprise licensing for namespace isolation (if using Vault) adds $30-120 per server per month for licensing, plus compute for the additional vault server overhead. For AWS Secrets Manager or Azure Key Vault, per-tenant costs are minimal — both services charge per secret and per API call, with per-tenant cost typically $5-20/month per tenant for a typical AI agent configuration.

Engineering investment: Building per-tenant credential provisioning workflows, BYOC pipelines, and credential lifecycle automation requires engineering time. Initial implementation: 2-6 weeks of platform engineering. Ongoing maintenance: 0.1 FTE.

Audit log storage: Per-tenant audit logs (with 7-year retention for compliance) generate significant storage volumes at scale. At 1 GB of logs per tenant per year and $0.023/GB-month (S3), 100 tenants generate $27.60/month in storage costs — negligible.

Total cost estimate for 100-tenant platform: $15,000-40,000 one-time engineering + $3,000-8,000/year ongoing = approximately $40,000-50,000 total over 3 years.

Risk Reduction Value

The expected value of credential isolation is the probability of a shared-credential breach multiplied by the breach cost reduction:

• Annual probability of credential compromise without isolation: ~18% (industry average for shared API key environments)
• Average cost of breach affecting all tenants (in a shared-key environment): $8-15M (customer notification, forensics, regulatory, reputation)
• Average cost of breach affecting 1 tenant (in an isolated environment): $200K-400K

Expected annual loss without isolation: 18% × $10M = $1.8M Expected annual loss with isolation: 18% × $300K = $54K Annual risk reduction value: $1.75M

ROI: $1.75M annual risk reduction vs. $15,000/year ongoing cost = 115:1 return.

This calculation makes the investment case for per-tenant credential isolation essentially unassailable for any platform with meaningful enterprise customers.

Customer Communication and Contractual Commitments on Isolation

Enterprise customers who understand credential isolation requirements will ask pointed questions during vendor due diligence. Being prepared for these questions — and having accurate, verifiable answers — is a commercial advantage for vendors who have implemented proper isolation.

The Due Diligence Questions Customers Ask

"What is your credential storage architecture for multi-tenant deployments?"

The correct answer describes the isolation mechanism (per-tenant vault namespaces, per-tenant AWS accounts, BYOC architecture) and the enforcement layer (cryptographic, not just application-layer policy). If the answer is "we have policies that prevent credential access across customers," the customer's next question will be "how is that enforced and verified?" Policy-only isolation doesn't satisfy enterprise security requirements.

"Can you demonstrate that a compromise of one customer's agent cannot expose another customer's credentials?"

This question requires either a live demonstration (isolation testing in a sandbox environment) or a third-party security assessment report that specifically addresses credential isolation. Vendors that can produce this evidence win enterprise deals; vendors that can only describe their architecture at a high level are less credible.

"What is your breach notification commitment if our credentials are involved in a security incident?"

Per-tenant isolation means the vendor can give a precise answer: "If there is a security incident affecting your tenant's credentials, we will notify you within [X] hours of discovery. The incident will affect only your tenant's credentials, not other customers' credentials." This is a significantly better answer than "we will notify all affected customers" — which implies that a breach affecting one customer's credentials will trigger notifications to all customers.

"What audit evidence can you provide of our tenant's credential access?"

Per-tenant isolation enables per-tenant audit trails — the vendor can produce a log of every access to the customer's credentials, with timestamps, requesting agent identity, and the action performed. This audit evidence is valuable for the customer's own compliance purposes and is only possible with proper per-tenant isolation.

Contractual Commitments for Credential Isolation

Enterprise contracts for multi-tenant AI agent platforms should include explicit credential isolation commitments:

Data processing agreement (DPA) language: "Provider maintains cryptographic isolation of Customer's credentials from credentials belonging to other customers. Access controls are enforced at the storage layer and verified through automated testing on a monthly basis."

Breach notification language: "Provider will notify Customer within 24 hours of discovering any security incident that affects or may affect Customer's credentials. Provider will maintain records demonstrating that the incident was contained to Customer's tenant and did not affect other customers' credentials."

Audit rights language: "Customer has the right to request audit evidence of all accesses to Customer's credentials within the prior 90 days. Provider will provide this evidence within 5 business days of a written request."

Right to audit language: "Customer may, upon 30 days' written notice, engage a qualified independent security firm to conduct an isolation testing assessment of Provider's multi-tenant credential architecture. Provider will cooperate with such assessment and provide access to test environments."

Vendors who can commit to these contractual provisions — because their architecture supports them — win enterprise deals that vendors with weaker isolation architectures cannot. The contractual commitments are a commercial differentiator directly enabled by the technical isolation architecture.

Conclusion

Credential sharing across tenants is the multi-tenant AI agent security failure that's simultaneously most common and most severe. Common because it's easy to implement initially and the security failure isn't obvious until a breach occurs. Severe because when it does occur, every customer is affected simultaneously.

The fix is architectural: per-tenant credential vaults, enforced at the storage layer with cryptographic isolation, not just application-layer policy. This requires upfront engineering investment — provisioning per-tenant vault namespaces, implementing ABAC-based access control, or building BYOC credential injection pipelines — but that investment pays dividends in customer trust, compliance posture, and breach blast radius.

Enterprise customers increasingly have the sophistication to evaluate credential isolation architecture during vendor due diligence. Vendors that can demonstrate cryptographic per-tenant isolation win deals that vendors relying on "our policy prohibits cross-tenant access" lose. The credential isolation architecture is increasingly a differentiator, not just a compliance checkbox.

The trajectory is clear: as AI agents proliferate in regulated industries, credential isolation standards will move from best practice to regulatory requirement. EU AI Act provisions on data minimization, NIST AI RMF trust requirements, and sector-specific guidelines from OCC, HIPAA, and PCI DSS are all moving in the direction of mandating technical isolation rather than accepting policy isolation as adequate. Organizations that implement per-tenant credential isolation today are making an architectural investment that will satisfy requirements that don't yet exist as formal mandates. Those that delay are accumulating technical debt that becomes progressively harder and more expensive to address as tenant counts grow and isolation requirements become non-negotiable contractually and regulatorily. Armalo's trust scoring already penalizes shared credentials across tenants — making credential isolation an economic consideration for agents seeking marketplace access, not just a compliance consideration for the platforms hosting them.