--- title: "Use of Scripts" slug: "use-of-scripts-v6-6" description: "AppGate ZTNA enhances access control with scriptable processes, ensuring secure integration with external systems while safeguarding credentials and logs." tags: ["Access Criteria Scripts", "Device Claim Scripts", "Entitlement Scripts", "Scripts"] updated: 2026-02-23T19:31:05Z published: 2026-02-23T19:31:05Z canonical: "support.appgate.com/use-of-scripts-v6-6" --- > ## Documentation Index > Fetch the complete documentation index at: https://support.appgate.com/llms.txt > Use this file to discover all available pages before exploring further. # Use of Scripts The AppGate ZTNA system has evolved to allow almost all parts of the access control process flow to be made scriptable. This allows the system to inter-operate with countless external systems and network environments. Effectively the system can now learn who might need what access rights; which Actions are allowed when; then the system goes and finds any available live hosts. ![Diagram illustrating device sign-in, token passing, and access criteria in a system architecture.](https://cdn.us.document360.io/e7482ce5-acfa-4c3b-b76c-b6c32472644a/Images/Documentation/ag53-scripts2.png?sv=2026-02-06&spr=https&st=2026-10-26T22%3A05%3A12Z&se=2026-10-26T23%3A05%3A12Z&sr=c&sp=r&sig=JdRxrB3SdwQCEdufj6PqwGmUrE%2FBqnk%2BhLeihXAfsF4%3D) Scripts can be used throughout AppGate ZTNA and perform complex logic, string manipulations and calculations, but an important part of this capability is to allow limited [https calls](/v1/docs/advanced-external-https-calls-v6-6) to be made to external systems. For these calls, there is a [Secrets](/v1/docs/secrets-v6-6) store built into AppGate ZTNA so that any credentials required to authenticate to these external systems are not exposed in the scripts themselves or any related logs. The Access and Identity sections of the admin UI allow you to add a number of these scrips (before using them) in the AppGate ZTNA system. Additionally, [(assignment) criteria](/v1/docs/configure-policies-v6-6) scripts can optionally be created directly within Policies, [access criteria scripts](/v1/docs/configure-conditions-v6-6) are always created directly within Conditions and [resource names](/v1/docs/configure-entitlements-v6-6) are entered directly into the (protected) hosts field when defining Entitlement Actions. ## Before you Start - Read about [automation and orchestration](/v1/docs/automation-and-orchestration-v6-6). - Refer to [External https calls](/v1/docs/advanced-external-https-calls-v6-6). - Check out the [Appgate SDP GitHub](https://github.com/appgate/sdp) home page. - Refer to the [Nashorn ECMAScript 6 documentation](https://openjdk.java.net/jeps/292) for details of the features available in the javascript expressions used in AppGate ZTNA. ## Requirements/Considerations Use of these advanced tools require structured design, engineering and maintenance to ensure that system performance is not impacted and to avoid potential end-user issues. Here are a few of the things that should be considered before embarking on any scripting exercise: ### Things to consider #### Making calls to external systems ***Pre-configure trusted certificates***. Certificates relating to the use of https:// to talk to external systems should be added to [Trusted Certificates](/v1/docs/trusted-certificates-v6-6). ***Pre-configure any Secrets***. Credentials required to authenticate to these external systems should be added to the [Secrets](/v1/docs/secrets-v6-6) store. This ensures that these credentials are not exposed in the scripts themselves or any related logs. > [!NOTE] > NOTE > > This is only used for javascript based scripts - so does not apply to Device Claim Scripts or Resource Names. #### Security Any appliance JavaScript code runs in a sandboxed Nashorn JavaScript engine which is built in to AppGate ZTNA. The sandboxing refers to the configuration of the JavaScript engine which runs the JavaScript code. For example the JavaScript engine does not allow access to local file system and has only a subset of available java functions (which excludes btoa and atob). #### Trust Any script which passes through or runs on untrusted environments should be considered untrusted. The most obvious example of this is the Device Claim Script. This is sent to an untrusted machine and is likely to be harvesting data which in itself cannot be trusted. By example the script may be reading a registry setting - but the user of the device may be able to set or influence the value of that registry setting. #### Safety The author of the JavaScript code and the customer is responsible for code safety and the review of the code. For example programming an endless loop can bring the system down (there is no execution time limitation). #### Audit It is possible to inject log records into the Audit Logs from a Script. This might be useful to help with diagnostics or to provide an audit trail to show how an access decision was reached. This can be done for: - Policy assignment Scripts on Controllers - Condition and Entitlement Scripts on Gateways​ All you have to do is to include one or more audit log entries in your script such as: `var result = true;auditLog("OK");return result;` > [!NOTE] > **NOTE** > > event_type is a mandatory field in all audit logs - and for scripts will appear as an evaluation_log ### Scripts supplied by AppGate​ Any script provided via the AppGate Professional Service team or as example scripts from the manual are delivered as is, without warranty of any kind. AppGate disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. Any maintenance needs arising out of the use or performance of these sample scripts (and related documentation) remains the responsibility of the customer.