Tenant isolation

Authentication confirms who the caller is; tenant isolation ensures that each caller can access only the data belonging to their organization. AVX enforces isolation at three complementary layers.

IAM condition keys

Every Lambda handler that reads or writes data carries a tenant-scoped IAM execution role. DynamoDB, Bedrock KB Retrieve, and AgentCore Memory calls are bounded by IAM condition keys that express the permitted tenant scope:

{
  "Condition": {
    "StringEquals": {
      "dynamodb:LeadingKeys": "${aws:PrincipalTag/tenantId}/<key>"
    }
  }
}

The aws:PrincipalTag/tenantId tag is set when the Lambda execution role is assumed; it is supplied from the validated Cognito claim and cannot be overridden by the caller. This means that even if a request somehow carries a manipulated tenant context in the request body, the IAM condition on the underlying API call will reject any attempt to read outside the principal’s permitted partition.

DynamoDB partition-key prefixing

All AVX DynamoDB tables use a composite partition key of the form <tenantId>#<entityId>. For example, a vehicle-state record for vehicle V-001 in tenant t-fleet-01 has the partition key t-fleet-01#V-001. A caller authenticated as tenant t-rental-07 will never produce a GetItem or Query that resolves to a t-fleet-01#* key because the partition key is constructed server-side from the validated custom:tenantId claim, not from client-supplied input.

The prefix convention applies uniformly to: * Vehicle state and live telemetry records * Session and conversation state * Booking and STAR ticket records * Tenant-specific configuration overrides

Per-tenant knowledge bases

Knowledge base grounding is tenant-scoped in two ways:

1. Per-tenant Bedrock KB. Each tenant’s corpus — service policies, brand-specific warranty terms, fleet SLA definitions, operator-supplied documentation — resides in a dedicated Bedrock Knowledge Base. The KB ID for a tenant is stored in the tenant config record and loaded at session start; no cross-tenant KB lookup is possible because the KB ARN is resolved from the tenant config, not from user input.

2. Shared cross-tenant KB with source-category filtering. Cross-brand reference content (NHTSA recall bulletins, OBD-II DTC guides, NHTSA Vehicle Safety Standards) lives in a shared KB. The source_category metadata filter is set server-side on every Retrieve call so that a retrieval issued in a fleet-operator session cannot surface rental-policy content or vice versa.

For the cross-account grant model that backs KB access in multi-account deployments, see Building on CMS and ADP.