Permissions reference - Kore.ai Docs

Back to role management A permission is a single action a role may perform, and the platform identifies each one with a resource:action string. You build a custom role by selecting permissions, so this page tells you what each one grants before you grant it. The permission picker shows identifiers and nothing else. Read this page alongside it, because an identifier names the resource but rarely warns you about the consequence.

Permission groups

Build agents

Agents: Creating, editing, running, and deleting agent definitions.
Tools: Authoring the tools agents call, and invoking them directly.
Workflows: Authoring multi-step workflows, plus running published and draft ones.
Versions: The version lifecycle from creation through review, approval, and publication.
Prompt library: Authoring, testing, and promoting shared prompts.
Modules: Building modules, publishing them to the catalog, and importing them.
Namespaces: The namespaces that organize project resources.
External agents: Registering agents that run outside the platform.
Field intelligence: Field intelligence configuration and the data behind it.

Knowledge and data

Knowledge base: Knowledge content, and who can reach it.
Agent tables: Structured tables agents read and write, including sensitive columns.
Lookup data: Reference data for field validation and fuzzy matching.
Attachments: Files that move through conversations.
Survey templates: Feedback surveys agents present to users.

Running and operating

Sessions: Live conversation sessions, including sending into one.
Recordings: Reaching recordings, changing recording settings, and the restricted immutability grant.
Human tasks: Work items routed to people, and who assigns or claims them.
Approvals: Approval requests agents and workflows raise.
Outbound calls: Calls the platform places rather than receives.
Email operations: Email channel operations, recovery, and remediation.
HTTP async: Asynchronous HTTP operations.
Voice playground: Live voice testing and live session debugging.

Deployment and configuration

Solution Workbench: Workbench configuration and the release path.
Deployments: Creating and retiring deployments.
Environments: Environment configuration and deploying into one.
Environment variables: The runtime values agents resolve.
Channels: Channel definitions.
Channel connections: Live connections to external messaging platforms.
Config: General project configuration.
Runtime config: Project-wide runtime behavior settings.
Model config: Model selection and feature routing.

Access, security, and privacy

Auth profiles: Stored credentials, and the separate grant that decrypts them.
Credentials: Credential records, including rotation and assignment.
Connections: Connections to external systems.
Proxy: Proxy configuration for outbound traffic.
External secret sources: Connections to external secret managers.
Platform keys and secrets: Read access to platform-level keys and secrets.
Guardrails and PII: Guardrails on agent output, and PII detection patterns.
Privacy: Grants that reverse redaction and expose withheld data.
KMS: Encryption key management.

Analysis and quality

Analytics and simulate: Analytics access and simulation runs.
Evals: Authoring and running evaluations.
Experiments: Experiment configuration and results.
Optimization and auto-loop: Optimization runs, and applying their recommendations.

Workspace and governance

Workspace: Workspace settings, membership, and billing.
Governance: Governance policy, the audit trail, and the qualification gate.

How to read this reference

The platform groups permissions by resource, and the groups follow the picker’s categories so you can follow the on-screen permissions. Selecting a group header selects every permission inside it. Make sure that you only provide the necessary and required permissions when granting group-level permissions. Two behaviors affect what you can actually select.

Grant scope: Your can grant permissions as per your role. The picker may display some permissions that it doesn’t let you select in case these permissions are outside your own role’s scope.
Restricted permissions: Only a workspace owner or a higher role can grant a few permissions. It is possible that some permissions can’t be selected even by an admin.

Build agents

These permissions cover authoring work: the agents themselves, the tools and workflows they call, the prompts behind them, and the version history that tracks every change.

Agents

These permissions govern agent definitions. Reading an agent and running one are separate grants, so a role can exercise an agent without seeing how you built it.

Permission	Description
`agent:read`	Lets the role open agent definitions and configuration.
`agent:create`	Lets the role add new agents to the project.
`agent:update`	Lets the role change existing agent definitions.
`agent:delete`	Lets the role remove agents.
`agent:execute`	Lets the role run an agent. Grant it to testers who need to exercise behavior without editing it.

Tools

These permissions govern the tools agents call. Execution stays separate from authoring here too, because a tool that reaches an external system acts on real data whoever triggers it.

Permission	Description
`tool:read`	Lets the role open tool definitions, including endpoints and auth bindings.
`tool:write`	Lets the role create and change tools.
`tool:delete`	Lets the role remove tools.
`tool:execute`	Lets the role invoke a tool directly.

Workflows

These permissions govern multi-step workflows. Draft invocation sits apart from ordinary execution, so you can let someone test an unreleased workflow without letting them run published ones.

Permission	Description
`workflow:read`	Lets the role open workflow definitions.
`workflow:write`	Lets the role change workflow definitions.
`workflow:create`	Lets the role add new workflows.
`workflow:update`	Lets the role update existing workflows.
`workflow:delete`	Lets the role remove workflows.
`workflow:execute`	Lets the role run a published workflow.
`workflow:draft_invoke`	Lets the role run a workflow before anyone publishes it, which is what testers need ahead of a release.

Versions

These permissions govern the version lifecycle, from cutting a version through review, approval, and publication. Each stage carries its own permission so that different people can author and approve, which is the point of having a review stage at all.

Permission	Description
`version:read`	Lets the role open version history and version contents.
`version:create`	Lets the role cut a new version from current work.
`version:update`	Lets the role change a version that nobody has published yet.
`version:delete`	Lets the role remove a version.
`version:publish`	Lets the role publish a version, which makes it available to deploy.
`version:qualify`	Lets the role mark a version as qualified, recording that it met the checks your process requires.
`version:review`	Lets the role review a version and record the outcome.
`version:approve`	Lets the role approve a version. Keep it separate from `version:create` where your process needs a second pair of eyes.
`version:archive`	Lets the role archive a version, which takes it out of active use but keeps it.

Prompt library

These permissions govern shared prompts. Promotion sits apart from editing, so prompt authors can iterate freely while a smaller group decides what becomes canonical.

Permission	Description
`prompt:create`	Lets the role add prompts to the library.
`prompt:read`	Lets the role open prompts and their versions.
`prompt:update`	Lets the role change existing prompts.
`prompt:delete`	Lets the role remove prompts.
`prompt:test`	Lets the role run a prompt to judge its output.
`prompt:promote`	Lets the role promote a prompt version to the one other work uses.

Modules

These permissions govern reusable modules, both the ones this workspace publishes and the ones it imports. Publishing exposes your work to other projects, so scrutinize that grant hardest.

Permission	Description
`module:read`	Lets the role open modules and their contents.
`module:manage`	Lets the role create and change modules.
`module:publish`	Lets the role publish a module to the catalog, where other projects can adopt it and inherit later versions.
`module:import`	Lets the role import a module into this project.

Namespaces

These permissions govern the namespaces that organize project resources.

Permission	Description
`namespace:read`	Lets the role open namespaces.
`namespace:create`	Lets the role add namespaces.
`namespace:update`	Lets the role rename or reconfigure namespaces.
`namespace:delete`	Lets the role remove namespaces.

External agents

These permissions govern the agents that run outside the platform and take delegated work from this project.

Permission	Description
`external_agent:create`	Lets the role register an external agent.
`external_agent:read`	Lets the role open external agent registrations.
`external_agent:update`	Lets the role change an external agent registration.
`external_agent:delete`	Lets the role remove an external agent registration.

Field intelligence

These permissions govern field intelligence configuration and the data it draws on.

Permission	Description
`field_intelligence:read`	Lets the role open field intelligence configuration.
`field_intelligence:preview`	Lets the role preview results without applying them.
`field_intelligence:write`	Lets the role change field intelligence configuration.
`field_intelligence:refresh`	Lets the role refresh the underlying data.
`field_intelligence:import`	Lets the role import field intelligence definitions.

Knowledge and data

These permissions cover the content agents answer from and the structured data they read and write.

Knowledge base

These permissions govern knowledge content and who can reach it. Writing documents and writing permissions stay separate, so a content author doesn’t also control access.

Permission	Description
`knowledge_base:read`	Lets the role open knowledge bases and their contents.
`document:write`	Lets the role add and change documents in a knowledge base.
`permission:write`	Lets the role change who can reach knowledge base content.

Agent tables

These permissions govern the structured tables agents read and write. Hold back the reveal permission, because it exposes values the table otherwise masks.

Permission	Description
`table:read`	Lets the role open table structure and contents that carry no sensitive marking.
`table:write`	Lets the role add and change table records.
`table:delete`	Lets the role remove tables or records.
`table:sensitive:reveal`	Lets the role see values in columns marked sensitive. Grant it only where someone’s job requires the underlying data rather than a masked view of it.

Lookup data

These permissions govern the reference data behind field validation and fuzzy matching.

Permission	Description
`lookup_data:read`	Lets the role open lookup tables and their values.
`lookup_data:write`	Lets the role create and change lookup data.
`lookup_data:delete`	Lets the role remove lookup tables.

Attachments

These permissions govern the files that move through conversations.

Permission	Description
`attachment:read`	Lets the role open and download attachments.
`attachment:write`	Lets the role upload attachments.
`attachment:delete`	Lets the role remove attachments.

Survey templates

These permissions govern the feedback surveys agents present to users.

Permission	Description
`feedback-survey:create`	Lets the role add survey templates.
`feedback-survey:read`	Lets the role open survey templates.
`feedback-survey:update`	Lets the role change survey templates.
`feedback-survey:delete`	Lets the role remove survey templates.
`feedback-survey:write`	Lets the role change survey content.

Conversations and operations

These permissions govern live conversations and the operational work around them. They reach production traffic, so they carry more day-to-day risk than the authoring grants above.

Sessions

These permissions govern conversation sessions. Sending a message into a live session means speaking as the agent in front of a real user, so treat it as an operational grant rather than a diagnostic one.

Permission	Description
`session:read`	Lets the role open session records and transcripts.
`session:create`	Lets the role start a session.
`session:write`	Lets the role change session data.
`session:close`	Lets the role end an active session.
`session:execute`	Lets the role run agent turns inside a session.
`session:delete`	Lets the role remove session records.
`session:send_message`	Lets the role put a message into a live session.

Recordings

The platform generates recordings automatically during a call, so none of these permissions creates one. They govern who reaches a recording, who changes the recording settings, and who places a recording beyond deletion. Where an action lives matters as much as who holds the permission. The Sessions page offers playback and download only. Deletion and immutability live on the Recordings page, so a role holding recording:delete still finds no delete control on Sessions.

Permission	Description
`recording:read`	Lets the role play and download recordings. Two conditions have to hold: the project must have recording enabled, and the role must carry this permission. A role holding it still reaches nothing while recording stays off for the project.
`recording:write`	Lets the role change recording configuration, covering whether recording runs, how long the platform keeps recordings, and the remaining recording settings. It controls configuration rather than creation, because the platform already creates recordings on its own.
`recording:delete`	Lets the role delete recordings from the Recordings page.
`recording:mark_immutable`	Lets the role mark a recording immutable, which puts it beyond deletion for retention or legal hold. The platform restricts this grant, so an admin building a custom role can’t select it. It comes from the workspace owner or arrives with the highest-level project role.

Human tasks

These permissions govern the work items the platform routes to people. Assigning and claiming differ: you assign work to someone else, and you claim work for yourself.

Permission	Description
`human_task:read`	Lets the role open human tasks and see their state.
`human_task:assign`	Lets the role assign a task to someone else.
`human_task:claim`	Lets the role take an unassigned task.
`human_task:resolve`	Lets the role complete a task and record the outcome.

Approvals

These permissions govern the approval requests that agents and workflows raise.

Permission	Description
`approval:read`	Lets the role open approval requests and see their status.
`approval:write`	Lets the role record an approval decision.

Outbound calls

These permissions govern the calls the platform places rather than receives.

Permission	Description
`outbound_call:initiate`	Lets the role place an outbound call. The call reaches a real person, so this belongs with operational roles rather than build roles.
`outbound_call:read`	Lets the role open outbound call records.

Email operations

These permissions govern email channel operations, including recovery and remediation. Several of them act on messages already in flight, which is why they sit apart from ordinary channel permissions.

Permission	Description
`email:proactive_send`	Lets the role send email that the agent starts rather than sends in reply.
`email:diagnose`	Lets the role investigate delivery problems.
`email:replay`	Lets the role push a message through the pipeline again.
`email:delivery_recovery`	Lets the role retry failed deliveries.
`email:quarantine_release`	Lets the role release a quarantined message, which overrides the check that held it.
`email:message_erase`	Lets the role erase a message permanently. Nothing recovers it afterward, so keep this grant narrow.
`email:health_read`	Lets the role open channel health metrics.
`email:alert_policy_update`	Lets the role change the policies that trigger email alerts.
`email_exchange:delta_reset`	Lets the role reset the Exchange delta sync state, which forces a full resynchronization.
`email_exchange:subscription_cleanup`	Lets the role clear stale Exchange subscriptions.

HTTP async

These permissions govern asynchronous HTTP operations.

Permission	Description
`http_async:read`	Lets the role open asynchronous request state.
`http_async:manage`	Lets the role configure asynchronous request handling.
`http_async:send_message`	Lets the role send a message through an asynchronous channel.

Voice playground

These permissions govern live voice testing. Live debugging exposes conversation content as it happens, which puts it closer to a privacy grant than a testing one.

Permission	Description
`playground:use`	Lets the role run voice conversations in the playground.
`session:debug:live`	Lets the role inspect a live session while it runs.

Deployment and configuration

These permissions govern what reaches each environment and how the runtime behaves once it arrives.

Solution Workbench

These permissions govern the workbench and its release path. The release permission works with the release environment scoping described above, so grant both together and scope them deliberately.

Permission	Description
`workbench:read`	Lets the role open workbench configurations.
`workbench:write`	Lets the role change workbench configurations.
`workbench:configure`	Lets the role change workbench settings.
`workbench:integration_test`	Lets the role run integration tests.
`workbench:release`	Lets the role release configurations, limited to the environments the role’s scoping allows.
`workbench:restore`	Lets the role restore a previous configuration.

Deployments

These permissions govern deployments. Retiring one takes an agent out of service, so it reaches live traffic.

Permission	Description
`deployment:read`	Lets the role open deployments and see their status.
`deployment:create`	Lets the role create a deployment.
`deployment:retire`	Lets the role retire a running deployment.

Environments

These permissions govern deployment environments.

Permission	Description
`environment:read`	Lets the role open environment configuration.
`environment:deploy`	Lets the role deploy into an environment.

Environment variables

These permissions govern the runtime values agents resolve. Agents resolve variables at runtime, so a change here reaches new sessions without a redeploy.

Permission	Description
`env_var:read`	Lets the role open variable keys and any value the project doesn’t mark secret.
`env_var:create`	Lets the role add variables.
`env_var:update`	Lets the role change variable values.
`env_var:delete`	Lets the role remove variables. Anything still referencing a removed variable hits a runtime resolution error.

Channels

These permissions govern channel definitions.

Permission	Description
`channel:read`	Lets the role open channel configuration.
`channel:create`	Lets the role add a channel.
`channel:update`	Lets the role change channel configuration.
`channel:delete`	Lets the role remove a channel.

Channel connections

These permissions govern the live connections between channels and external messaging platforms.

Permission	Description
`channel_connection:read`	Lets the role open connection configuration and status.
`channel_connection:create`	Lets the role establish a connection.
`channel_connection:update`	Lets the role change a connection.
`channel_connection:delete`	Lets the role remove a connection, which stops traffic on that channel.

Config

These permissions govern general project configuration.

Permission	Description
`config:read`	Lets the role open configuration values.
`config:write`	Lets the role change configuration values.

Runtime config

These permissions govern runtime behavior settings, which apply project-wide to every deployment.

Permission	Description
`runtime_config:read`	Lets the role open runtime configuration.
`runtime_config:write`	Lets the role change runtime configuration. One change here reaches every agent in the project at once.

Model config

These permissions govern which models the project uses and how features route to them.

Permission	Description
`model_config:read`	Lets the role open model selection and feature routing.
`model_config:write`	Lets the role change model selection, tier bindings, and feature overrides, which moves both cost and output quality.

Access, security, and privacy

These permissions govern credentials, encryption, and access to protected data. Grant them most sparingly, because several expose material that other controls exist to hide.

Auth profiles

These permissions govern stored credentials. Decryption stands apart from every other action here, because reading a profile’s configuration differs from reading its secret.

Permission	Description
`auth-profile:read`	Lets the role open profile configuration. Secrets stay masked.
`auth-profile:create`	Lets the role create auth profiles.
`auth-profile:write`	Lets the role change auth profiles.
`auth-profile:delete`	Lets the role remove auth profiles.
`auth-profile:decrypt`	Lets the role see the stored secret. This grant turns credential management into credential access.

Credentials

These permissions govern credential records.

Permission	Description
`credential:read`	Lets the role open credential metadata.
`credential:write`	Lets the role create and change credentials.
`credential:delete`	Lets the role remove credentials.
`credential:manage`	Lets the role administer credentials, including rotation and assignment.

Connections

These permissions govern connections to external systems.

Permission	Description
`connection:read`	Lets the role open connection configuration.
`connection:write`	Lets the role create and change connections.
`connection:delete`	Lets the role remove connections.

Proxy

These permissions govern proxy configuration for outbound traffic.

Permission	Description
`proxy:read`	Lets the role open proxy configuration.
`proxy:write`	Lets the role change proxy configuration.
`proxy:delete`	Lets the role remove proxy configuration.

External secret sources

These permissions govern connections to external secret managers.

Permission	Description
`secret-source:read`	Lets the role open external secret source configuration.
`secret-source:write`	Lets the role configure an external secret source.
`secret-source:delete`	Lets the role remove an external secret source, which breaks anything that resolves secrets through it.

Platform keys and secrets

These permissions give read access to platform-level keys and secrets. Both stay read-only, because you create and rotate these through the pages that own them.

Permission	Description
`api_key:read`	Lets the role open API key metadata.
`secret:read`	Lets the role open stored secrets.

Guardrails and PII

These permissions govern the guardrails that constrain agent output and the patterns that detect personal data.

Permission	Description
`guardrail:read`	Lets the role open guardrail configuration.
`guardrail:write`	Lets the role change guardrails, which changes what the platform blocks in production.
`pii-pattern:read`	Lets the role open PII detection patterns.
`pii-pattern:write`	Lets the role change PII patterns. Weakening one pattern cuts redaction everywhere that pattern applies.

Privacy

These permissions open data that the platform redacts or withholds by default. Every one of them reverses a protection, so grant them individually and only for a stated purpose.

Permission	Description
`pii:reveal`	Lets the role see personal data that redaction would otherwise mask.
`sip-ladder:reveal`	Lets the role see SIP signalling detail for voice calls.
`session:debug:payload:read`	Lets the role read raw session payloads, including content that ordinary session views leave out.
`provider-payload:read`	Lets the role read the raw payloads the platform exchanges with model providers.

KMS

These permissions govern encryption key management.

Permission	Description
`kms:admin`	Lets the role administer key management, including provider selection, rotation policy, and failure policy.

Analysis and quality

These permissions cover measurement and improvement work: reading analytics, running evaluations, and applying optimizations.

Analytics and simulate

These permissions govern analytics access and simulation runs.

Permission	Description
`analytics:read`	Lets the role open analytics data and dashboards.
`simulate:execute`	Lets the role run simulations on agents.

Evals

These permissions govern evaluations. Authoring an evaluation and running one stay separate, so a tester can run a suite without changing what it measures.

Permission	Description
`eval:read`	Lets the role open evaluation definitions and results.
`eval:write`	Lets the role create and change evaluations.
`eval:run`	Lets the role run evaluations.

Experiments

These permissions govern experiments.

Permission	Description
`experiment:read`	Lets the role open experiment configuration and results.
`experiment:write`	Lets the role create and change experiments.

Optimization and auto-loop

These permissions govern automated optimization. Applying an optimization changes agent behavior, which is why it sits apart from running one.

Permission	Description
`optimization:read`	Lets the role open optimization runs and their recommendations.
`optimization:run`	Lets the role start an optimization run.
`optimization:apply`	Lets the role apply an optimization’s recommendations to the agent.

Workspace and governance

These permissions cover the workspace itself and the controls that bound what everyone else can do.

Workspace

These permissions govern workspace settings, membership, and billing.

Permission	Description
`tenant:read`	Lets the role open workspace configuration.
`tenant:update`	Lets the role change workspace details.
`tenant:manage_settings`	Lets the role change workspace-level settings.
`tenant:manage_members`	Lets the role add and remove workspace members and change their roles.
`billing:read`	Lets the role open billing and usage information.
`billing:write`	Lets the role change billing configuration.

Governance

These permissions govern governance policy and the audit trail. Weigh the qualification gate bypass separately from everything else here, because it removes a control rather than configuring one.

Permission	Description
`governance:write`	Lets the role change governance configuration.
`governance:audit-read`	Lets the role read the governance audit trail. Avoid pairing it with an operational role, so the person reviewing activity isn’t the person performing it.
`production:bypass_qualification_gate`	Lets the role release to production without the qualification the gate demands. It exists for genuine emergencies, and any role that holds it permanently defeats the gate.
`approval_policy:write`	Lets the role change the policies that decide what needs approval, which hands it control over the approval requirement itself.

​Permission groups

​How to read this reference

​Build agents

​Agents

​Tools

​Workflows

​Versions

​Prompt library

​Modules

​Namespaces

​External agents

​Field intelligence

​Knowledge and data

​Knowledge base

​Agent tables

​Lookup data

​Attachments

​Survey templates

​Conversations and operations

​Sessions

​Recordings

​Human tasks

​Approvals

​Outbound calls

​Email operations

​HTTP async

​Voice playground

​Deployment and configuration

​Solution Workbench

​Deployments

​Environments

​Environment variables

​Channels

​Channel connections

​Config

​Runtime config

​Model config

​Access, security, and privacy

​Auth profiles

​Credentials

​Connections

​Proxy

​External secret sources

​Platform keys and secrets

​Guardrails and PII

​Privacy

​KMS

​Analysis and quality

​Analytics and simulate

​Evals

​Experiments

​Optimization and auto-loop

​Workspace and governance

​Workspace

​Governance

Permission groups

How to read this reference

Build agents

Agents

Tools

Workflows

Versions

Prompt library

Modules

Namespaces

External agents

Field intelligence

Knowledge and data

Knowledge base

Agent tables

Lookup data

Attachments

Survey templates

Conversations and operations

Sessions

Recordings

Human tasks

Approvals

Outbound calls

Email operations

HTTP async

Voice playground

Deployment and configuration

Solution Workbench

Deployments

Environments

Environment variables

Channels

Channel connections

Config

Runtime config

Model config

Access, security, and privacy

Auth profiles

Credentials

Connections

Proxy

External secret sources

Platform keys and secrets

Guardrails and PII

Privacy

KMS

Analysis and quality

Analytics and simulate

Evals

Experiments

Optimization and auto-loop

Workspace and governance

Workspace

Governance