Delinea Authorization Powered by Iris AI
This feature is currently available only to customers participating in a Private Preview. If you'd like to participate and be among the first to try this feature, ask our support or account team for details.
Delinea Authorization powered by Iris AI (Iris Authorization) is an AI-powered access-approval agent that automates Secret Server approval workflows, streamlining the process and reducing the risk of unauthorized access while enhancing compliance with existing security policies.
Iris Authorization evaluates each access request based on:
-
the requester's identity
-
the requester's stated intent
-
contextual risk signals
-
historical patterns
-
your organization's policies
Iris Authorization vs. Manual Approval
Traditional manual access approvals can be time-consuming for both administrators and users, are prone to human error, and may not adequately assess the risk associated with each request.
Iris Authorization addresses these challenges with automation based on comprehensive data, enhancing security and efficiency while still enabling human administrators to analyze approvals and intervene as necessary.
Most importantly, Iris Authorization will not grant additional access beyond what is requested. In addition, administrators are able to give feedback on past approvals, allowing Iris Authorization to learn and adapt over time to improve its decision-making capabilities.
Recommendation vs. Automated Decision
Iris Authorization operates in two primary modes: recommendation only and automated decision.
| Mode | Behavior |
|---|---|
| Decide | Iris Authorization automatically approves or denies the request |
| Recommend | Iris Authorization only recommends an action; a human still approves/denies |
In the recommendation mode, Iris Authorization provides suggestions to a human approver (who receives the request and suggestion in the Inbox).
In the automated decision mode, Iris Authorization can approve or deny requests based on predefined criteria.
The process flows like this:
-
Request Submission: A user submits an access request, including a ticket number and justification (unless you modify the instructions to exclude these requirements).
-
Risk Assessment: Iris Authorization evaluates the requestor's risk score, location, business hours, and other contextual signals.
-
Ticket Verification: Iris Authorization retrieves and analyzes the content of the associated ticket (from systems like Zendesk or ServiceNow).
-
Decision Making: Based on the analysis, Iris Authorization either denies the request or recommends approval to a human approver.
-
Feedback Loop: Administrators can provide feedback on Iris Authorization's decisions, which is used to improve the system's accuracy over time.
Decision Factors
When Iris Authorization evaluates an access request, it considers the following (non-exhaustive) checks:
-
User risk level – Critical/high-risk users require stricter scrutiny
-
User behavior and deviation from baseline
-
Failed login attempts
-
Location anomalies
-
MFA use
-
-
Secret access request
-
Justification is reasonable and professional
-
Is not excessive in duration
-
-
If an IT Service Management (ITSM) connection is available
-
Ticket number – Matches the ITSM ticket (e.g., Zendesk) with the access request
-
Ticket justification – Request reason must align with ticket description
-
Configuring Iris Authorization
Iris Authorization must be enabled initially and then configured with a profile (which provides guidance on approval logic) and then associated with a Secret Server access request workflow. Workflows can involve multiple approvers, including humans and non-humans.
Enable Iris Authorization
A Platform Admin role is necessary to view Iris Authorization page to enable the feature.
-
Navigate to the Settings page from the Home page.
-
Navigate to the Iris Authorization page.
-
Select Edit.
-
Change the State switch to Enabled.
-
Accept the AI usage agreement.
Grant Permissions
A user with the Platform Admin role can grant manage and view privileges to users via the following permissions. A user with Platform Admin role will inherit Iris Authorization manage permissions by default.
-
delinea.platform/irisauthorization/manage: Grants a user permission to manage Iris Authorization profiles, connectors, and access requests.
-
delinea.platform/irisauthorization/view: Grants a user permission to view Iris Authorization profiles, connectors, and access requests.
Create a Profile with Authorization Checks
Iris Authorization profile configuration helps implement authorization checks (security policy) to assess secret access requests.
-
Navigate to the Iris Authorization page, focus will land on the Configuration tab.
-
Select Add profile. The Profile pane appears.
-
Choose a name for the profile.
-
Select Recommend or Decide.
-
Select authorization checks to be included in the profile.
-
Choose default checks.
-
Optionally add one or more custom checks.
-
-
Associate a service user with the profile.
-
Select Managed Service Account to create and associate a service user automatically.
-
Select Existing Credentials to associate a previously created service user with the profile.
-
-
Preview Checklist will display the final checklist that combines default and custom checks. Information about applicability of custom check(s), inclusion in the final checklist, special cases and reason is also provided.
-
Save profile to land on the Configuration tab.
Choose Default Checks
Defaults or built-in checks can be included or excluded in assessing a secret request workflow. The following table explains default checks that are currently supported.
| Name | Description | Default state | Source |
|---|---|---|---|
| Check user risk level | Consider the likelihood of user account compromise | Selected | Analytics |
| Check if user used MFA1 | Check if user authenticated with MFA in their recent logins | Selected | User audit logs |
| Check request access duration | Validate that the duration the resource is requested for is reasonable and not excessive | Selected | Secret access request |
| Check request justification appropriateness | Validate that the access justification is reasonable, specific, professional and contextually appropriate to the requested resource | Selected | Secret access request |
| Check user justification against ticket(s) | Consider how the requester's stated intent matches with details of the ITSM ticket provided in the secret access request | Conditional2 | ITSM integration via MCP connector(s) |
1 Signal restricted to platform-authenticated users, so recommend deselecting this option if you expect federated users for whom the evaluation would fail this check.
2 Selected if an ITSM (Zendesk, ServiceNow) Model Context Protocol (MCP) connector is enabled in the tenant. Unselected and disabled if no ITSM MCP connector is enabled in the tenant.
Add one or more Custom Checks (Optional)
Custom checks are an experimental feature that helps specify authorization checks in natural language. These checks are optional and can modify or complement the default checks to implement specific security policy. One or more custom checks can be added to the profile. Preview Checklist control on the profile configuration screen provides real-time feedback on the applicability and effectiveness of custom checks added and can be reviewed before a profile is saved. The experimental nature of custom checks means that unexpected results may be encountered in access request evaluations. In such cases, AI Agent Feedback (Thumbs up or flag) and comments on the evaluation result page will help in making custom checks more effective in future. Some examples of custom checks are provided in the table below.
| Category | Example | Source(s) |
|---|---|---|
| Modify default check | Check for access request duration only if it is >30 minutes | Secret access request |
| Combine default checks | Check for FIDO MFA if user risk level is high or critical | User audit logs, Analytics |
| Failed login attempts | Do not approve if login failure rate is >75% in the last 3 days | User audit logs (last 30 days) |
| Location anomalies | Check for location anomalies | Analytics Alerts (last 24 hours) |
| Day of week and time of day | Check to ensure that the access request was submitted Monday through Friday, between 8 A.M. and 5 P.M. US eastern standard time | Secret access request |
| Access request justification text | Check for "#ScheduledMaintenance" in request justification | Secret access request |
| Secret property | Allow access only if secret template is Active Directory Account and RDP is enabled | Secret Server |
| Secret metadata | Check to make sure that user exists in user metadata field of the secret | Secret Server |
| Ticket status | Approve only if the ticket is "In progress" and has been approved | ITSM system |
| Ticket creator | Check to make sure that the requester is not the same as the one that created the ticket | ITSM system |
| Ticket Configuration Item | Check to make sure that the configuration item in the ticket match application the secret is associated with | ITSM system, Secret Server |
| Override condition | Do not check for any other condition and always approve if secret is classified low risk and user risk level is low or better | Secret Server, Analytics |
Tips for writing effective Custom Checks
| Do | Don't |
|---|---|
| Specify checks against attributes currently supported. E.g. User risk level; MFA used; Failed login attempts; Ticket details like status, created by, created datetime; Secret access request details like duration, justification text, created by | Use attributes that are not supported. E.g. device security status, malware scan results, user is active on payroll, user completed infosec training |
| Include conditions to check that are specific and objective. E.g. "user risk level is low", "Requester is not the same as creator of the ticket", "Access request is not submitted on a Saturday or Sunday" | Use non-instructive, vague or ambiguous criteria for checks. E.g. "user is trustworthy", "user security is high" |
Associate a service user to work with the Profile
A service user is necessary and works within a profile to gather required information across the platform to help with access request evaluation. A service user is unique to a profile. A service user can be automatically created with necessary permissions (recommended), or an existing one can be added to the profile during configuration.
Select Managed Service Account to create and associate a service user automatically
A service user will be automatically created and associated to the profile. This is the recommended option due to the following reasons:
-
Service user will be created with the same display name as the profile.
-
The display name is critical in adding the service user as an approver in an access request workflow in the next step.
-
Authentication certificate created will be managed automatically.
Select Existing Credentials to associate a previously created service user with the Profile
An existing service user can be associated with the profile using this option. However, this approach is not recommended due to the following overheads:
-
Permissions necessary to work with Iris Authorization will have to be added manually.
-
The password associated with the account will have to be maintained.
See Creating a service user, and make sure that the following permissions are assigned to the account:
-
delinea.platform/audit/event/read
-
delinea.platform/identity/admin/read
-
delinea.platform/administration/users/read
-
delinea.vault/secretserver/secret/read
Assign the Service User to a Workflow
Once the Profile is created and the service user has sufficient permissions, the service user must be assigned to a workflow. You may add it to an existing workflow, or create a new one.
NOTE: If you want the service user to "Recommend" only, do not place it in the final step of the workflow, since a positive recommendation there actually approves access.
See Accessing the Workflow Designer in Secret Server for workflow creation and editing.
Integrating with your eTicket System
Integration with Zendesk or ServiceNow supplies Iris Authorization with ticket context (e.g., confirming that a database bug-fix ticket exists for the request).
NOTE: If you do not use a ticket system, you must edit the authorization instructions in the profile to remove mention of tickets.
ZenDesk Integration
To connect to Zendesk from the Delinea Platform:
-
Navigate to the Add Connector page.
-
Select Zendesk and enter the following:
-
Display Name
-
Base Address
-
API Key
-
Email (API user)
-
-
Click Save.
ServiceNow Integration
To connect to ServiceNow from the Delinea Platform:
-
Navigate to the Add Connector page.
-
Select ServiceNow and enter the following:
-
Display Name
-
Base Address
-
API Key
-
Email (API user)
-
-
Click Save.
Viewing Access Requests
To view access requests managed by Iris Authorization, navigate to the Access Requests tab on the Iris Authorization page. (NOTE: this is different from the Secret Access Requests page)
The columns show:
-
Secret: the secret the access is requested for
-
User: the requesting user
-
Profile: the Iris Authorization profile used
-
Decision: Approve, Deny, Recommend Approve, Recommend Deny, Cancelled
-
Requested date: access request created date and time
To view additional data about a specific access request, click its row on the table. Data include:
-
Secret
-
Requester user account
-
Request date and time
-
Reason for request: From the secret access request
-
Profile: The Iris Authorization profile used in the evaluation
-
Decision: the final decision made by Iris Authorization
-
Decision summary: A brief description of how Iris Authorization arrived at the final decision.
-
Validation Checklist: Individual evaluation steps with result (pass, fail), data used, and rationale for result
-
Reasoning: A synthesis of results from the validation checklist, compared with the authorization checks configured in the profile that describes the decision-making process of Iris Authorization.
-
Additional information
-
Mode: Decide or Recommend mode configured in the profile
-
Time taken: Time taken by Iris Authorization to arrive at the final decision.
-
Service user: The username (different from the display name) of the service user configured on the profile.
-
Custom checks: Custom checks configured on the profile
-
The final section, AI Agent Feedback, lets you rate Iris Authorization's decisions and add detailed comments.
-
Thumbs up – Indicates the decision was appropriate
-
Flag – Indicates the decision or its reasoning was incorrect or needs improvement
This feedback is collected by our AI operations backend to continuously improve Iris Authorization's accuracy.
Validating your Configuration
Delinea strongly suggests testing each new profile in a variety of scenarios with low-risk secrets. You may need to adjust the authorization checks for optimal results.
Iris Authorization Safety Statement
Human-AI Oversight Requirement
Delinea Authorization powered by Iris AI (Iris Authorization) is designed to augment your skilled oversight – not to replace it. Iris Authorization can be set either to alert you or to take pre-specified actions. This automation still requires a "human on the loop" for customer oversight, audit and feedback, to ensure accuracy and to optimize results over time. AI models are probabilistic in nature, meaning they can inherently produce outputs that are inaccurate or incomplete. You and your end users bear responsibility for any decisions, recommendations, actions, or inactions that arise from utilizing Delinea Authorization powered by Iris AI.
Data Privacy and Processing
Delinea Authorization powered by Iris AI uses the Azure OpenAI service provided by Microsoft. Key data handling and privacy features include the following:
-
Regional Data Hosting: Your tenant data is hosted and processed within the same region that you have selected for your cloud operation, ensuring compliance with regional data handling regulations. Any feedback that you send to Delinea ("debugging data") can be stored in other regions (see Data Included in Feedback to Delinea below).
Due to local data hosting requirements, Iris AI (Delinea Authorization Powered by Iris AI and Delinea Auditing Powered by Iris AI) is not available in the United Arab Emirates.
- Data Deletion After Processing: When Azure OpenAI finishes processing data from a Delinea Platform access request, the data is immediately deleted from Azure and not retained by Microsoft. This ensures that evaluation data is handled securely and transiently.
- No AI Training with Customer Data: Delinea Authorization powered by Iris AI does not and will not use customer recordings or data to train AI models unless we obtain your specific prior written authorization to do so.
- Data Included in Feedback to Delinea: When a user flags an Iris Authorization recommendation or decision, the specific data involved (their feedback explanation, the original access request, and the contextual risk data for that request) will become visible to Delinea engineers for troubleshooting analysis and resolution only.
Enabling the AI Agreement
In addition to enabling the Delinea Authorization powered by Iris AI capability, you must approve the AI Agreement before Iris Authorization can begin reviewing access requests.
To enable Iris Authorization for the first time:
-
From the left navigation, select Settings > Iris AI > Authorization.
-
Toggle the Iris Authorization State to Enabled.
-
Review and approve the Delinea AI Agreement.