Handle tenancy boundaries

Ensure AI-generated code selects tenants explicitly, scopes resource access correctly, and enforces role-based permissions so it never crosses tenancy lines in a Veracity integration.

Veracity is a multi-tenant platform. Every API call operates within a tenant context, and every resource belongs to a specific tenant. An AI agent (a program such as Cursor, GitHub Copilot, or Claude Code that uses an LLM to read your code, run commands, and call APIs) generates integration code from training data that does not include your tenant topology. Code that omits explicit tenant selection can silently operate against the wrong tenant, return data the caller should not see, or write to a resource that belongs to a different organisation.

Before you start

You need:

• A Veracity developer account with at least one registered application
• The tenant IDs for the tenants your application is authorised to access
• The Veracity Development MCP Server configured in your agent so it can retrieve current Veracity Tenant Management API documentation

Write tenant-aware code

1. Identify the tenant context for every operation before you prompt your agent. Know which tenant ID your code should operate against and include that in the prompt: "Generate a resource query scoped to tenant ID {your-tenant-id}: do not assume a default tenant."

2. Ask your agent to retrieve the current Veracity Tenant Management API documentation before writing tenant-selection code. Instruct the agent: "Check the Veracity documentation for the correct way to specify tenant context on this API call." This ensures the generated code uses the current parameter name and placement, not an outdated pattern from training data.

3. Review every API call the agent generates and confirm that the tenant identifier is passed explicitly. Do not rely on implicit defaults. If the agent generates code that calls an endpoint without a tenant parameter, add it before testing.

4. Confirm that resource access is scoped to a single tenant per request. AI-generated code that iterates over resources sometimes queries all resources visible to the service account rather than those belonging to the target tenant. Add a tenant filter at the query level, not as a post-query filter in application code.

5. Apply role-based permission checks at the point where data is read or written, not only at the entry point of your application. AI-generated middleware commonly centralises permission checks at the route level. For Veracity integrations, also confirm permissions at the resource level. A user's role in one tenant does not imply the same role in another.

6. Use minimal permission scopes on every service account. When you ask your agent to scaffold an integration, it does not know which Veracity permission scopes your service account holds. Review the generated code against the scopes your account actually has, and remove any permission requests that exceed what the integration requires.

Verify the integration

Before deploying AI-generated code that operates across tenants:

• Run the integration against a test tenant and confirm it returns only resources belonging to that tenant.
• Authenticate as a user with a restricted role and confirm the integration correctly denies access to resources outside that role's scope.
• Introduce a resource from a second tenant into the test environment and confirm the integration does not return it.
• Check that no tenant identifiers, resource IDs, or role assignments are hard-coded as literals in the generated code.

Limitations

• The Veracity Development MCP Server provides current API documentation but does not have visibility into your tenant topology or service account permission grants. Tenant IDs and role assignments must be confirmed separately in the Veracity developer portal.
• AI agents cannot infer tenancy requirements from code structure alone. Always specify the tenant context explicitly in every prompt that involves resource access.
• Veracity Tenant Management covers tenant selection and resource scoping. Regulatory data access controls (for example, vessel data consent) are governed separately: see Handle regulated data.