Security

The Alation Agent Skills plugin is a local CLI tool. It runs on the user’s machine, sends requests to the organization’s Alation instance, and returns the response. It has no server component, stores no data, and runs no AI models of its own.

This page covers how authentication works, what data the plugin accesses, which external endpoints it contacts, and how it enforces Alation’s role-based access controls.

Compliance and certifications

For an overview of Alation Cloud Service security controls, encryption, and key management, see the Alation Cloud Service Security page.

Enterprise security reviews

For SOC 2 Type II reports, audit scope, penetration test summaries, and HECVAT/CAIQ questionnaires, contact your Alation account manager. Security materials are available under NDA.

The plugin is open-source under Apache 2.0. The full source code is available at Alation/alation-plugins and can be independently audited. It collects no telemetry, usage analytics, or diagnostic data — verifiable by reading the source.

Architecture

The plugin runs locally with no server-side component. All catalog search, data browsing, and query execution happen inside the customer’s Alation environment. Query results flow back to the plugin and appear in the user’s AI session; they pass through the workstation but are never persisted by the plugin.

Note

Most plugin operations (catalog search, metadata browsing, SQL execution) go directly to Alation and return results with no LLM involved. An LLM call only happens when a user explicitly sends a message to an Alation AI agent, at which point Alation (not the plugin) calls the configured provider.

What data the plugin accesses

The plugin returns two categories of information:

Category	Examples	Persisted by plugin?
Catalog metadata	Table names, column names, schema descriptions, tags	No
Query results	Rows returned by SQL run against a data product	No

Query results and the AI assistant

Data reaching the AI assistant's LLM

Query results returned by the plugin are passed into the AI assistant’s context window (Claude, Copilot, Gemini, etc.). The AI assistant may in turn send that context, including query result rows, to its own LLM provider as part of normal operation. This is outside the scope of the plugin and outside Alation’s control.

Organizations with strict data residency or output restrictions should apply controls at the AI assistant layer. Relevant controls include data classification policies on the AI assistant, output filtering, and user consent workflows for sensitive data products.

What is sent to an LLM

The ask skill can chat with AI agents created in Alation Agent Studio via python -m cli chat send, and invoke individual tools via python -m cli tool call. Both commands hit Alation’s /ai/api/v1/chats/ endpoints. The plugin never contacts an LLM directly; Alation handles the LLM call internally on the user’s behalf.

By default, agents run on Alation’s infrastructure and use AWS Bedrock as the LLM provider. Admins can also connect their own LLM credentials through Bring Your Own Model (BYOM), which supports AWS Bedrock, Azure OpenAI, OpenAI, Anthropic, Google Vertex AI, and OpenAI-compatible providers.

Alation may send catalog metadata to the LLM as context, depending on the agent’s configuration and the user’s query. Metadata that may be sent includes:

• Object names (table name, column names and types)
• Descriptions, titles, and tags
• Linked query SQL text
• Lineage information
• Search results

SQL execution tool and row-level data

When an agent uses the SQL execution tool, actual query results, including row-level data, are sent to the LLM as part of the agent’s reasoning context. This tool only runs when the user has configured data warehouse credentials for the data product and explicitly consents to execute the query.

Authentication

The plugin uses OAuth 2.0 with PKCE. The full login flow is shown below.

Note

No passwords are stored by the plugin. Tokens are sent only to the customer’s Alation instance and never to the AI assistant, any LLM provider, or any third party.

Token lifetimes

Admins can adjust these in Alation admin settings.

Token	Default	Configurable range
Access token	24 hours	1 hour to 3 days
Refresh token	60 days	3 days to 180 days

IdP federation

Alation supports integration with external identity providers. When IdP federation is configured, Alation validates incoming JWT tokens against the IdP’s JWKS endpoint instead of managing credentials locally. Users authenticate through their existing corporate SSO without a separate Alation credential.

Provider	Support level
Microsoft Entra ID	Certified
Okta	Certified
Auth0	Supported
Other JWT-based IdPs	Best effort

See User-Initiated OAuth Clients for setup instructions.

RBAC enforcement

The plugin does not bypass Alation’s access controls. Every request carries the user’s identity token, and Alation enforces the same permissions that apply when the user logs into the Alation web interface. See Roles and Permissions for the full role hierarchy.

Control	Behavior
Catalog visibility	Users only see data sources, schemas, and tables they have been granted access to in Alation
Data product access	Users can only query data products that are published and accessible to their role
Agent and tool access	Draft agents are visible only to their creator and admin-tier roles; published agents are visible to all authenticated users
Query execution	SQL runs using Alation-managed database credentials; users never see or control the underlying connection

Role	Access via the plugin
Server Admin / Catalog Admin	All published and draft resources
Composer, Steward, Source Admin	Their own drafts and all published resources
Viewer, Explorer	Published resources only

Summary

Property	Detail
Transport	HTTPS (TLS) for all communication
Authentication	OAuth 2.0 with PKCE
IdP federation	Microsoft Entra ID, Okta, Auth0 supported
Token lifetimes	Access: 24h default (1h to 3d); Refresh: 60d default (3d to 180d)
Token storage	~/.alation/token_cache.json, chmod 0600
Token revocation	Suspending a user in Alation prevents new logins; existing tokens expire per their configured lifetime
Authorization	Alation enforces RBAC on every request
Data sent to Alation’s LLM	Catalog metadata only; actual data values never sent by Alation to the LLM
Query results and AI assistant	Query results pass into the AI assistant’s context window; controls at the AI assistant layer apply
Network	Outbound HTTPS to Alation hostname only; HTTPS_PROXY supported for corporate proxies
Telemetry	None
Source code	Open-source, Apache 2.0
Compliance	See Alation Cloud Service Security; SOC 2 Type II available under NDA via account manager