Effective Permissions

Veza classifies individual system permissions into Data, Metadata, and NonData categories based on the type of access they grant.

Effective permissions provide a normalized view of access across Veza integrations. Instead of requiring a deep understanding of each provider's unique permission model, Veza translates raw system permissions into canonical categories: Data, Metadata, and NonData.

Effective permissions appear throughout Veza's search interfaces. For example, in Query Builder, you can filter results by the effective permission level a principal has on a resource (such as DataWrite or MetadataRead).

Permission in Query Builder

In Access Graph, permission nodes display the effective categories that explain what actions a principal can take on a resource.

System permissions are the raw permissions as defined in the source system, such as s3:GetObject, SELECT, kms:Decrypt in AWS. Effective permissions are Veza's normalized interpretation of what those permissions mean in terms of access to data and infrastructure. This normalization enables consistent access analysis across heterogeneous environments.

The relationships and permissions in search results depend on the Query Mode. Effective mode shows permissions after applying all restrictions and deny policies, while System mode shows configured authorization relationships as they exist in source systems.

Permission categories

Veza classifies individual system permissions into three categories based on the type of access granted:

1. Data: Permissions that allow direct access to stored business content. This might include reading database records, file contents, secrets, or configuration values.

2. Metadata: Permissions that manage infrastructure resources, access controls, and configurations without accessing the business content itself.

3. NonData: Permissions for control plane operations that do not involve reading, writing, or managing access to content.

Category	Subcategories	What the permission allows	Examples
Data	DataRead, DataWrite, DataCreate, DataDelete	Access to stored business content	Database rows, file contents, S3 objects, secrets
Metadata	MetadataRead, MetadataWrite, MetadataCreate, MetadataDelete	Infrastructure and configuration management	Encryption keys, IAM policies, access configurations
NonData	None	Control plane operations	Rebooting instances, canceling queries

These subcategories enable granular filtering in Query Builder. For example, you can search for identities with DataWrite access versus DataRead access to distinguish between different levels of permissions on the same resource.

How classification works

A single service typically has permissions across multiple categories, depending on what each permission allows.

Example: Amazon S3

An S3 bucket can have related permissions that span categories:

• s3:GetObject → DataRead - Accesses the content of stored objects

• s3:GetBucketPolicy → MetadataRead - Reads the bucket's access configuration

• s3:PutBucketPolicy → MetadataWrite - Modifies the bucket's access configuration

• s3:GetAccountPublicAccessBlock → NonData - Reads account-level public access settings

The same bucket can have both Data permissions (allowing reading objects), and Metadata permissions (for modifying the bucket's ACL or logging configuration), assigned to different principals.

Classification criteria

When distinguishing Data from Metadata permissions, the determining factor is whether the permission allows access to the content or governs operations on the infrastructure containing the content:

Permission characteristic	What the permission allows	Classification
Access stored content	Reading/writing business data	Data
Manage access controls	Modifying IAM policies, ACLs, permissions	Metadata
Configure infrastructure	Creating resources, setting configurations	Metadata
Provide cryptographic ops	Encrypting, decrypting, key operations	Metadata
Control plane operations	Rebooting, canceling, account settings	NonData

Implementation and edge cases

While the criteria above provide the general philosophy for classification, implementation decisions are made at the integration level depend on the specific entity type. Edge cases may exist where classification decisions require judgment calls based on provider-specific architecture. Any unusual classifications should be documented in the individual integration guides.

Reference examples

The following tables show how Veza classifies specific permissions across different services.

AWS

The following examples show how AWS permissions are classified based on what they allow you to do.

Service	System permission	Effective	Reasoning
S3	s3:GetObject	DataRead	S3 stores the object
S3	s3:PutBucketPolicy	MetadataWrite	Modifying access configuration
Secrets Manager	secretsmanager:GetSecretValue	DataRead	SM stores the secret value
Secrets Manager	secretsmanager:DescribeSecret	MetadataRead	Reading configuration, not value
SSM	ssm:GetParameter	DataRead	SSM stores the parameter value
KMS	kms:Decrypt	MetadataRead	KMS provides key ops, not storage
KMS	kms:Encrypt	MetadataRead	KMS provides key ops, not storage
KMS	kms:CreateKey	MetadataCreate	Creating infrastructure
IAM	iam:CreateRole	MetadataCreate	Creating access infrastructure
S3	s3:GetAccountPublicAccessBlock	NonData	Account-level settings

Note on KMS: KMS doesn't store encrypted data. It provides cryptographic operations using keys. When you call kms:Decrypt, the encrypted data comes from another service (S3, a database, etc.). Compare this to secretsmanager:GetSecretValue, considered DataRead because Secrets Manager stores the secret value. The same logic applies to kms:Encrypt and kms:GenerateDataKey.

Databases

Database permissions follow the same pattern: queries on stored content are Data permissions, schema and access control operations are Metadata permissions, and administrative operations are NonData.

System	Permission	Effective	Reasoning
Snowflake	SELECT	DataRead	Reading table content
Snowflake	INSERT	DataWrite	Writing new records
Snowflake	CREATE TABLE	MetadataCreate	Creating database structure
Snowflake	GRANT	MetadataWrite	Modifying access controls
Snowflake	OPERATE	NonData	Warehouse control operations
Snowflake	EXECUTE TASK	NonData	Running scheduled tasks
PostgreSQL	SELECT on pg_roles	DataRead	Reading table content (see note)
PostgreSQL	GRANT on pg_roles	MetadataWrite	Modifying access controls

System tables and information schemas: Database system tables like PostgreSQL's pg_roles, pg_users, or information_schema tables store information about users, roles, schemas, and access controls. While this content describes identity and access infrastructure, querying these tables is classified as DataRead because the permission grants access to stored table content. The classification is based on what the permission allows you to do (reading table rows) rather than what the content represents. Similarly, SELECT permissions on these tables are DataRead, while GRANT permissions that modify access to them remain MetadataWrite.

Related topics

• Query Modes - Effective vs system mode in searches

• Query Builder - Searching with permission filters

• Filters - Permission and attribute filters