Appian Knowledge Base

KB-2386 Log ingestion pipelines fail for login-audit.csv after upgrading to Appian 25.4

pauline.delacruz — Mon, 15 Jun 2026 16:05:32 GMT

Current Revision posted to Appian Knowledge Base by pauline.delacruz on 6/15/2026 4:05:32 PM

Symptoms

After upgrading to Appian 25.4, automated log ingestion pipelines (such as Splunk, Datadog, ELK, or custom Appian expression rules) that process the <APPIAN_HOME>/logs/login-audit.csv file and rely on strict positional parsing or headerless formats may fail or parse data incorrectly.

As a result, administrators may experience a temporary loss of login audit data visibility in downstream reporting stores, or trigger internal security/IT alerts due to these ingestion job failures.

Cause

This issue is caused by schema changes introduced in Appian 25.4 to support the new "Multi-Factor Authentication: Authenticator Apps" feature.

Pipelines relying on headerless parsing or strict positional index mapping will fail due to two structural modifications:

Inclusion of Headers: Row 1 of login-audit.csv now contains column headers. Historically, this file was headerless.
New MFA Tracking Column: A new column was appended to the log to track native MFA events.
- In Appian 25.4, this column was initially introduced as MFA User.
- In Appian Hotfix 25.4.371.0, this column was renamed to MFA Authenticated and its behavior was refined to accurately distinguish genuine Appian MFA events from SSO/LDAP authentications.
- Note: true indicates successful authentication using Appian native MFA, while false indicates external authentication (SSO/LDAP), primary authentication failure, or MFA not being enabled.

Strict positional parsing of the login-audit.csv file without accounting for the newly added header row is no longer a supported ingestion approach.

For more information about login-audit.csv, refer to Logging.

Action

To resolve this issue and prevent future disruptions, log ingestion scripts and parsers must be updated:

Account for the Header Row: Update ingestion scripts to ignore the first row as data, treating it instead as the schema definition.
Update Parsing Logic: Switch from positional indexing to header-based mapping (e.g., map by the exact header string MFA Authenticated). This guarantees pipeline stability even if column orders change in future releases.

Affected Versions

This article applies to Appian 25.4 and later.

Last Reviewed: June 2026

Tags: integration, authentication

KB-1575 How to enable loggers for commonly seen Appian issues

Kaushal Patel — Thu, 04 Jun 2026 16:33:56 GMT

Current Revision posted to Appian Knowledge Base by Kaushal Patel on 6/4/2026 4:33:56 PM

Purpose

In certain troubleshooting scenarios, it may be necessary to enable DEBUG logging to retrieve additional information related to the issue observed. This article details how to enable DEBUG logging for some of the most commonly seen issues in Appian. The DEBUG statements will be logged to the application server log, unless configured otherwise.

Instructions

Warning: Enabling the DEBUG logs in an environment can lead to large log files and introduce potential performance degradation. Appian Technical Support advises to enable loggers on lower environments before doing so on production.

The steps to enable DEBUG logging are as follows:

Open the appian_log4j.properties file. The location varies based on the version:
1. For Appian 25.4 and later, edit the config map containing the appian_log4j_override.properties file. If this is the first time the logging is being used, please follow the documentation to generate the appian_log4j_override.properties file
2. For Appian 18.3 and later, this file can be found in <APPIAN_HOME>/deployment/web.war/WEB-INF/resources.
3. For Appian 18.2 and earlier, this file can be found in <APPIAN_HOME>/ear/suite.ear/resources.
Find and uncomment the lines which apply to the particular issue you are trying to troubleshoot.
Set the value of the line to DEBUG.
Save and exit out of the file.

The steps to disable DEBUG logging are as follows:

Return to the appian_log4j.properties file, and update the lines you modified so that the value is changed from DEBUG back to ERROR.
Save the file and check the application server log to verify that the DEBUG and TRACE log entries are no longer being recorded.

When adding any of these loggers, check if they already exist in appian_log4j.properties, if they do, edit the existing line, otherwise add the lines to the appian_log4j.properties.

Loggers:

Appian Authentication, SAML, LDAP:

log4j.logger.com.appiancorp.security=DEBUG
log4j.logger.org.springframework.security=DEBUG
log4j.logger.org.opensaml.core.xml.util=TRACE

OpenID Connect User Authentication:

log4j.logger.com.appiancorp.security.auth.oidc=DEBUG

OAuth 2.0 Token Request Sequence:

log4j.logger.com.appiancorp.connectedsystems.http.oauth.HttpOAuthTokenRetriever=DEBUG
log4j.logger.com.appiancorp.connectedsystems.contracts.HttpOAuthTokenService=DEBUG
log4j.logger.com.appiancorp.connectedsystems.http.execution.strategies=DEBUG
log4j.logger.com.appiancorp.connectedsystems.http.oauth=DEBUG
log4j.logger.com.appiancorp.oauth.inbound=DEBUG

Application Import/Export:

log4j.logger.com.appiancorp.ix=DEBUG

Appian Health Check:

Note: Only applicable when using the Health Check Plugin. These loggers do not apply when Health Check is configured through the Admin Console.

log4j.logger.com.appiancorp.plugins.labs.BulkLogDownloadServlet=DEBUG
log4j.logger.com.appiancorp.tools.labs.analysis.util.LabsFileFilter=DEBUG
log4j.logger.com.appiancorp.healthcheck=DEBUG, HEALTH_CHECK

CDT Import/Export:

log4j.logger.com.appiancorp.type.external.teneoimpl.TeneoAnnotationsValidator=DEBUG
log4j.logger.com.appiancorp.type.external.teneoimpl.AppianHbSessionDataStore=DEBUG

Starting Processes by E-mail (email polling):

log4j.logger.com.appiancorp.messaging.MessagePublisherServiceImpl=DEBUG 
log4j.logger.com.appiancorp.process.execution.service.ProcessExecutionServiceFacade=DEBUG 
log4j.logger.com.appiancorp.mdb=DEBUG

Process Models Exposed as Web Services:

log4j.logger.com.appiancorp.process.webservices.pmserver=DEBUG

Process to Process Messaging:

log4j.logger.com.appiancorp.messaging.MessagePublisherServiceImpl=DEBUG 
log4j.logger.com.appiancorp.process.execution.service.ProcessExecutionServiceFacade=DEBUG

Query Timeouts:

log4j.logger.org.hibernate.util.JDBCExceptionReporter=DEBUG

Query RDBMS Execution and Validation:

log4j.logger.com.appiancorp.process.runtime.activities.QueryRdbmsActivity=DEBUG
log4j.logger.com.appiancorp.process.runtime.activities.JdbcActivity=DEBUG

Capture SQL Statements:

log4j.logger.org.hibernate.SQL=DEBUG
log4j.logger.org.hibernate.type=TRACE

SAIL (unmask pink pop-up errors):

log4j.logger.com.appiancorp.rest.shared.AppianExceptionMapper=DEBUG
log4j.logger.com.appiancorp.core.expr.tree.Variable=DEBUG
log4j.logger.com.appiancorp.core.expr.Parse=DEBUG

Sending Emails with Send Email Smart Service:

log4j.logger.com.appiancorp.process.runtime.activities.SendEmailActivity=DEBUG
log4j.logger.com.appiancorp.ap2.mail=DEBUG

Call Web Service Smart Service:

log4j.logger.com.appiancorp.ws=DEBUG
log4j.logger.org.apache.axis2=DEBUG
log4j.logger.httpclient.wire.header=TRACE
log4j.logger.org.apache.commons.httpclient=TRACE

Importing Web Service CDTs:

log4j.logger.com.appiancorp.type.config.xsd.SchemaFactory=DEBUG

Background activity in Appian Engines:

log4j.logger.com.appiancorp.process.background.EngineWorkSpringContextListener=DEBUG
log4j.logger.com.appiancorp.process.background.EngineWorkControllerFactory=DEBUG
log4j.logger.com.appiancorp.process.background.EngineWorkControllerRunnable=DEBUG
log4j.logger.com.appiancorp.process.background.EngineWorkController=DEBUG

Details on CDT Transformation:

log4j.logger.com.appiancorp.type.xmlconversion=DEBUG 
log4j.logger.com.appiancorp.suiteapi.common.TypeConverter=DEBUG 
log4j.logger.com.appiancorp.core.data.converter=DEBUG

High Transformation Time When Processing the Results Received from the RDBMS:

log4j.logger.com.appian.perflogs.ecore-tv-conversion-trace=INFO, ECORE_TV_CONVERSION_PERF_TRACE
log4j.additivity.com.appian.perflogs.ecore-tv-conversion-trace=false
log4j.appender.ECORE_TV_CONVERSION_PERF_TRACE=com.appiancorp.common.logging.AppianFileAppender
log4j.appender.ECORE_TV_CONVERSION_PERF_TRACE.layout=com.appiancorp.type.data.ecore.EcoreToTvConversionPerfLogger$TraceLayout
log4j.appender.ECORE_TV_CONVERSION_PERF_TRACE.File=${AE_LOGS}/perflogs/perf_ecore_tv_conversion_trace.csv
log4j.appender.ECORE_TV_CONVERSION_PERF_TRACE.MaxFileSize=10MB
log4j.appender.ECORE_TV_CONVERSION_PERF_TRACE.MaxBackupIndex=1000
log4j.appender.ECORE_TV_CONVERSION_PERF_TRACE.encoding=UTF-8

Workpoller Issues:

log4j.logger.com.appiancorp.ra.workpoller=DEBUG, WORK_POLLER

Plugin Deployment:

log4j.logger.com.appiancorp.process.admin=DEBUG

XSD Validation:

Note: This is used when record type validation fails or when deploying a plugin which constructs a CDT.

log4j.logger.com.appiancorp.type.config.xsd=DEBUG

HTTP Connected Systems Request Execution:

Note: This is to check the request contents, how it was received, if response was received or timed out, etc.

log4j.logger.com.appiancorp.connectedsystems.http=DEBUG
log4j.logger.com.appiancorp.connectedsystems.http.execution.AppianHttpRequestExecutor=DEBUG

Connected Environments DevOps:

log4j.logger.com.appiancorp.connectedenvironments.logging.DevOpsInfrastructureHandlerAuditLogger=DEBUG
log4j.logger.com.appiancorp.designobjectdiffs.functions.application.DodConnEnvCallSystemRuleHandler=DEBUG

Connected Environment (Retrieval of Public Keys):

log4j.logger.com.appiancorp.connectedenvironments.ConnectedEnvironmentPublicKeyRetriever=DEBUG
log4j.logger.com.appiancorp.connectedenvironments.service.ConnectedEnvironmentsInitialRequestor=DEBUG
log4j.logger.com.appiancorp.connectedenvironments.service.JwtUtils=DEBUG
log4j.logger.com.appiancorp.connectedenvironments.KeyUtils=DEBUG

Compare & Deploy (Inspection phase): Compare

log4j.logger.com.appiancorp.designdeployments.handler.DplConnEnvAsyncInspectHandler=DEBUG
log4j.logger.com.appiancorp.designdeployments.handler.DplConnEnvInspectHandler=DEBUG

Salesforce connected Systems (returns error stacktrace returned by Salesforce):

log4j.logger.com.appiancorp.connectedsystems.salesforce=DEBUG

Webserver (returns data transferred to and from the servers when executing HTTP requests): Quick Apps:

**these loggers are verbose, switch loggers to ERROR first before removing them from appian_log4j.properties file

log4j.logger.org.apache.http=DEBUG
log4j.logger.org.apache.http.wire=DEBUG

Quick Apps:

log4j.logger.com.appiancorp..object.quickapps.QuickAppObjectType=TRACE

Deployment Stuck in Progress:

log4j.logger.com.appian.kafka.KafkaTopicManager=DEBUG

Record Sync Incidents:

log4j.logger.com.appiancorp..record.data.recordloaders.ads.AdsReplicaTransaction=DEBUG
log4j.logger.com.appiancorp.record.fn.RefreshReplicaForRecordTypeReaction=DEBUG
log4j.logger.com.appiancorp.record.service.RecordReplicaUpdateService=DEBUG
log4j.logger.com.appiancorp.record.service.quartz.ReplicaLoadJob=DEBUG
log4j.logger.com.appiancorp.record.replicaupdate.LogRyowVsBulk=DEBUG
log4j.logger.com.appiancorp.record.service.ReplicaSyncPollerImpl=DEBUG
log4j.logger.com.appiancorp.record.service.quartz.scheduling.ScheduleManagerImpl=DEBUG
log4j.logger.com.appiancorp.record.service.quartz.LoggingTriggerListener=DEBUG

Affected Versions

This article applies to all versions of Appian.

Last Reviewed: June 2026

Tags: logging, administration, application server, how-to

KB-1161 "HTTP/1.1 413 Request Entity Too Large"/"Email body failed to render" errors thrown in application server log

pauline.delacruz — Mon, 01 Jun 2026 18:46:02 GMT

Current Revision posted to Appian Knowledge Base by pauline.delacruz on 6/1/2026 6:46:02 PM

Symptoms

Users may experience one of the following symptoms:

Symptom 1

The HTTP File Upload Smart Service fails to upload files larger than 64KB (the threshold can be larger) with the following message in the application server log:

com.appian.integration.httpclient.smartnode.HttpFileUploadSmartNode - ConnectorRuntimeException [title=HTTP error connecting to ##URL##, com.appian.integration.core.exception.ConnectorRuntimeException: HTTP/1.1 413 Request Entity Too Large]

In the smart service’s output, an HTTP response code of 413 is returned.

Symptom 2

Appian auto-generated email alerts are not sent by the server with the following error in the application server log:

... Caused by: java.io.IOException: Server returned HTTP response code: 414 for URL: XXXX Caused by: com.appiancorp.process.engine.EmailBodyException: Email body failed to render: MailBody{filename=/ntf/emailHtml/XXXX_emailHtml.jsp}

Symptom 3

When a specific user performs an action that works for other users, like clicking on a form, task or report, they receive a generic error like one of the following:

An internal error has occurred. The page could not be loaded. [HTTP Code = 413] (APNX-1-4279-001)

The System Has Encountered an Error. 
HTTP Code: 413
The system has encountered an error. Please try again later.

If using Apache, the following error can be observed in the mod_jk.log:

[error] ajp_marshal_into_msgb::jk_ajp_common.c (469): failed appending the header value” in the mod_jk log.

Symptom 4

The user experiences a HTTP 500 Error when navigating to: */suite/rest/a/applications/latest/app/design/monitoring:

The following entries are printed to the tomcat-stdOut.log:

com.appiancorp.rest.shared.FallbackExceptionMapper - Internal Server Error on REST API invocation. java.lang.IllegalArgumentException: Header message of length [x] received but the packetSize is only [8,192]  at org.apache.coyote.ajp.AjpProcessor.readMessage(AjpProcessor.java:636)  at org.apache.coyote.ajp.AjpProcessor.receive(AjpProcessor.java:577)

Cause

This usually occurs because the web server has received a request that is larger than the configured limit. The web server is currently configured to limit the file size and will throw an error when it receives a request that is too large.

Depending on the exact action being performed by the user, and the subsequent request being made to the web server, the error could be due to the size of the request’s header, message body or the total size of the request as a whole.

Action

To prevent this error from reoccurring, and to allow the requests to be fulfilled by the web server, raise the maximum allowed size for the area of the message (header, body, etc) that is causing the error.

For Symptoms 1 and 2

When the size of the request’s body is too large:

For IIS, the maxReceivedMessageSize parameter will have to be increased. By default, it is 64KB to prevent DOS attacks. For Apache, the parameter to be modified is LimitRequestBody.

For Symptoms 3 and 4

When the size of the request’s header is too large:

JBoss

Add the following properties to the JBoss standalone.xml file under the <system-properties> tag:

<property name="org.apache.coyote.http11.Http11Protocol.MAX_HEADER_SIZE" value="65535"/>

<property name="org.apache.coyote.ajp.MAX_PACKET_SIZE" value="65536"/>

Restart the application server.

Tomcat (Appian 21.2 and later)

Add the following properties inside the custom.properties file, located in <APPIAN_HOME>/conf.
```
conf.appserver.ajp.maxPacketSize=24576
```
```
conf.appserver.maxHeaderSize=65535
```
Note that the default value for the maxPacketSize is set to 8192 and for the maxHeaderSize, the max is 66536.
Restart the application server.

Note: Remember to update these configurations in custom.properties.<env> located inside <APPIAN_REPO>/conf/ for future deployments.

Tomcat (Appian 21.1)

Add the following property inside the custom.properties file, located in <APPIAN_HOME>/conf.
```
conf.appserver.maxHeaderSize=65535
```
Note The max value for maxHeaderSize is 66536.
Find the <connector> tag in the Tomcat server.xml file (Located in the directory <APPIAN_HOME>\tomcat\apache-tomcat\conf) for the AJP and HTTP protocol:
```
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443"/>
```
Add the packetSize property to the AJP tag, the default is set to 8192 and the max is 65536:
```
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" packetSize="24576"/>
```
Restart the application server.

Note: Remember to update these configurations in custom.properties.<env> located inside <APPIAN_REPO>/conf/ for future deployments.

Tomcat (Appian 20.4 and earlier)

Find the <connector> tag in the Tomcat server.xml file (Located in the directory <APPIAN_HOME>\tomcat\apache-tomcat\conf) for the AJP and HTTP protocol:

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443"/>

<Connector port="9080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443"/>

Add the packetSize property to the AJP tag, the default is set to 8192 and the max is 65536. Add the maxHttpHeaderSize property to the HTTP tag, the max is 65536:

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" packetSize="24576"/>

<Connector port="9080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" maxHttpHeaderSize="65535"/>

Restart the application server.

Additional Configurations if Using IIS as a Web Server

Add the following property to the IIS workers.properties file (Located in the directory <ISAPI_HOME>\conf) matching the AJP value previously set in the server.xml file:
```
worker.ajp13w1.max_packet_size=24576
```
```
worker.ajp13w2.max_packet_size=24576
```
Restart IIS.

Additional Configurations if Using Apache as a Web Server

In the Apache httpd.conf file (located in <APACHE_HOME>\conf), update or add the following properties to align with your Tomcat AJP configuration values:
- Set the maximum HTTP header field size to match the Tomcat maxHttpHeaderSize value:
```
LimitRequestFieldSize 65535
```
- Set the AJP worker packet size to match the AJP maxPacketSize configured in Tomcat’s server.xml or Appian’s custom.properties:
```
JKWorkerProperty worker.<node>.max_packet_size=X
```
  where:
  - <node> is the Tomcat/AJP worker node name defined in your Apache configuration.
  - X is the same value as your AJP maxPacketSize (for example, 24576).
Save your changes.
Restart the Apache web server for the new configuration to take effect.

If Error Code 413 only occurs for one user please proceed with the following steps:

Attempt to reproduce the issue while using the browser's Private/Incognito mode.
1. If the issue cannot be reproduced in Private/Incognito mode, continue with step 2.
2. If it the issue is still present, create a support case with Appian Support.
Clear the cache and all cookies on your browser using the instructions provided in the browser documentation.
Restart the browser and attempt to repeat the action that caused the 413 error.

If the steps above do not resolve the issue and the user is on Internet Explorer, continue with the following steps:

Select Tools > Developer Tools.
Select the Console tab.
Run the following string within the IE Dev Console: javascript:document.execCommand("ClearAuthenticationCache");
Press the Enter key.
The following should be output on the console:

Affected Versions

This article applies to all self-managed versions of Appian.

Last Reviewed: June 2026

Tags: email, web server, application server, 413, infrastructure

KB-2385 Plugin Review & Security Scanning FAQ

Ryan Good — Wed, 27 May 2026 18:11:29 GMT

Current Revision posted to Appian Knowledge Base by Ryan Good on 5/27/2026 6:11:29 PM

All plugins submitted to Appian for use on Appian Cloud require review and approval. This article aims to answer common questions about the plugin review process.

For more information on plugin and AppMarket policies, refer to the AppMarket Submission Policies documentation and the AppMarket Submissions Agreement.

Table of Contents:

How are plugin security reviews performed?
What specific tooling is used?
How often are reviews performed?
What happens to plugins that are flagged by security scans?
Can Appian provide the scan results?
What happens to plugins that are flagged by security scans?
How long do I have to remediate a finding in my plugin?
My plugin submission was previously approved. Why is my latest update not approved?
I need to use my plugin on Appian Cloud ASAP. Can I bypass security review temporarily?

How are plugin security reviews performed?

Security scanning is first performed during all submissions of new and updated plugins to Appian. Subsequent reviews are also performed on a routine basis after initial approval.
Scans such as Static Application Security Testing (SAST), Software composition analysis (SCA), and other security related checks are in place.

What specific tooling is used?

Appian utilizes custom tooling, open source software, and commercial off the shelf software to perform the automated security scanning.
Appian does not publish the specific software used to review plugins.

How often are reviews performed?

Reviews are always performed upon plugin submission. Post-approval, additional security reviews are performed regularly.
Appian reserves the right to perform security reviews at any time.

Do security reviews apply to private plugins?

Yes. As stated in the AppMarket Submission Policies, All plug-ins, whether intended for public use on the AppMarket or private use within an organization, must receive approval before deployment.

Can Appian provide the scan results?

Appian does not publish or share the results of security scans.
Plugin authors are notified directly when one of their submissions is flagged by a security scan.

What happens to plugins that are flagged by security scans?

Plugin authors are notified directly when one of their submissions is flagged by a security scan.
Plugins which are not updated may be removed from the AppMarket. Appian reserves the right to reject or stop hosting plug-ins at any time.

How long do I have to remediate a finding in my plugin?

Appian will provide a timeline for remediation when notifying you of a finding.
Appian reserves the right to modify plug-in remediation timelines at any time.

My plugin submission was previously approved. Why is my latest update not approved?

Every submitted version of a plugin is reviewed in full.
Approval of a plugin does not guarantee approval of subsequent versions.
Appian reserves the right to modify plugin security policies at any time.

I need to use my plugin on Appian Cloud ASAP. Can I bypass security review temporarily?

Plugin submissions cannot bypass security review; only fully approved submissions can be deployed on Appian Cloud.
If a plug-in requires expedited review, please include that context and justification in the submission.
If you subscribe to a Signature Appian Success Plan, let your Lead Engineer know of your urgent request.

Affected Versions

This article applies to all versions of Appian.

Last Reviewed: May 2026

Tags: FAQ, plugins

KB-2384 Appian's Response to AI-Accelerated Threats (Mythos, Daybreak, MDASH)

Kaushal Patel — Wed, 27 May 2026 16:49:21 GMT

Current Revision posted to Appian Knowledge Base by Kaushal Patel on 5/27/2026 4:49:21 PM

Executive Summary

Appian understands the concerns surrounding new, highly capable frontier models, such as Anthropic’s Claude Mythos Preview, and their potential to accelerate the discovery and exploitation of software vulnerabilities. Our position is that the core principles of robust cloud security continue to generate the most effective defense. Appian's security posture, built upon secure-by-design architecture, strict operational rigor, and deep partnership with Amazon Web Services (AWS), Chainguard, and others is actively managed to mitigate the risks introduced by AI-accelerated threats, ensuring the continued security and compliance of customer environments.

What is Mythos?

Claude Mythos Preview is a new large language model developed by Anthropic. It has demonstrated advanced capabilities in computer security tasks, particularly in identifying, analyzing, and potentially exploiting vulnerabilities in software. The critical industry insight regarding Mythos is not that it introduces fundamentally new vulnerability classes, but that it significantly reduces the time and expertise required for malicious actors to execute an AI-accelerated offensive, compressing traditional exploitation timelines.

What is Daybreak?

Daybreak is an OpenAI-developed frontier model, often discussed alongside Anthropic’s Mythos, associated with advanced AI reasoning capabilities. It is related to OpenAI's reasoning models like "o1" and "o3-mini" which are optimized for complex tasks such as programming. Like other frontier models, Daybreak's significance is its potential to accelerate AI-driven offense by making the discovery and exploitation of software vulnerabilities faster.

What is MDASH?

MDASH (which stands for Multi-model Dynamic/Agentic Scanning Harness or Multi-model Agentic Scanning Harness) is a highly advanced, AI-powered vulnerability discovery system developed by Microsoft. This system is designed for defensive use, rapidly identifying and addressing software vulnerabilities to help organizations 'defend at AI speed,' reflecting the industry-wide shift toward using AI to compress vulnerability discovery and exploitation timelines. This is what organizations today are doing relative to vulnerability discovery and remediation in code.

Appian’s Perspective

Appian’s position as a leading security organization is aligned with the community behind the Cloud Security Alliance (CSA) and Amazon Web Services (AWS): The appropriate response to AI-accelerated offense is an increased focus on foundational security controls. The CSA Mythos paper emphasizes that organizations must prioritize patch management, vulnerability remediation, and continuous monitoring to reduce the attack surface. Appian aligns with the AWS view that security is a shared responsibility, and that defense at scale requires continuous evolution of operational rigor, not reactive technology adoption. Our strategy is built on monitoring these developments and immediately integrating defensive learnings.

We’ve gained perspective with the industry surrounding frontier models, including effective use of existing foundational models for security purposes. These tools are good at recursive reading and discovery; their findings will reflect your own organization's security maturity. If you have “skeletons” in the closet, don’t enforce MFA, don’t enforce a good SDLC, don’t upgrade to the latest patches, these are the equivalent of leaving your home unlocked and windows open for a burglar.

We are actively engaged using tools available to us today, and take the opportunity that AI presents very seriously on behalf of Appian, you (our customers), and your customers. More on this below.

Appian’s Position

Appian’s approach to security is predictive, proactive, systematic, and aligned with the highest industry standards, providing essential mitigation against AI-accelerated threats. We jointly align with customers towards best practices to mitigate potential emergent threats and risks - AI or otherwise.

Secure-by-Design Infrastructure

Appian Cloud leverages the extensive security capabilities of AWS, relying on their expertise in securing the underlying cloud infrastructure. Our deep partnership ensures that Appian environments benefit from AWS’s scale, rigorous security controls, and immediate response capabilities. This includes leveraging identity and access management (IAM), network segregation, and continuous configuration checks provided by the cloud service provider. Frontier LLMs are good at finding security flaws within logic and code that when applied to standards, protocols, kernel, and supply-chains are the emergent threat fundamental to system operations; layering mature practices and response actions are required to keep pace.

Differentiated Platform Architecture

The Appian Platform architecture is fundamentally designed to reduce inherent risk and exposure:

Zero-Trust: Appian's architecture is built on Zero Trust principles: never trust, assume breach, and verify every access request. This is implemented via a multi-control point lattice, shifting defenses from static perimeters to focus on users, assets, and resources. Core components include strong identity, device health, continuous re-authentication, hyper least privilege, and encryption everywhere. This resilient platform design provides consistent security regardless of user location or data sensitivity.
Identity-Aware Access: All customer applications and data interactions are governed by a robust, fine-grained identity and access framework.
Multi-Tenant Controls: Strong logical separation is enforced across all multi-tenant environments, isolating customer data and reducing the potential impact of a single vulnerability.
Policy Enforcement and Auditability: The platform enforces strict security policies at every layer, providing comprehensive audit trails that enhance detection and response capabilities.

Integrated Security Development: We leverage both deterministic and AI-assisted/agentic tools directly into our continuous integration pipeline to automatically flag and help developers remediate vulnerabilities before code is promoted. We are also adapting the frequency of AI-assisted secure code reviews for our entire code-base to proactively hunt vulnerabilities. Continuous 3rd party White-Hat Hackers and penetration testing are used to further enhance our posture.
Our active investments in GenAI-driven security ensure continuous protection at the speed of development:
- AI-Powered Secure Design: We are augmenting security tools with additional AI-powered tools for architecture review and threat modeling to identify and fix flaws continuously in the agentic SDLCs, preventing issues before they are coded.
- Agentic Code Scanning: Security services in our SDLC have already been created as agent accessible tools to scan and remediate vulnerabilities directly inside developer environment tooling) and centrally enforced in code pipelines.
- Supply Chain Hardening: We are seeking additional hardened components similar to our use of Chainguard. We are migrating to private, vendor-managed third-party libraries and in our centralized artifact repository which governs all components, ensuring the integrity and provenance of our software supply chain against AI-accelerated attacks.

Mature Vulnerability Management Program

Appian maintains a mature, risk-based vulnerability management program that adheres to industry standards and regulatory expectations:

Prioritization and Remediation: We leverage systems like CISA’s Known Exploited Vulnerabilities (KEV) database, and plan to include additional exploitability and reachability metrics to prioritize remediation based on real-world threat exposure, ensuring a focus on the most critical risks.
Operational Rigor: Appian is committed to aggressive patching SLAs and maintaining Plan of Action and Milestones (POA&M) discipline. We are continuously improving our ability to rapidly deploy patches, specifically to meet the accelerated timelines suggested by AI-enabled offense.
Supply Chain Security: To proactively counter supply chain risks, Appian is migrating to private, curated third-party libraries for components, ensuring all dependencies are current, patched, and malware-free. We partner with industry leading firms on pre-hardened and pre-patched assets in our supply chain where possible.

Scaling Vulnerability Management: We are preparing for an order-of-magnitude increase in discovered vulnerabilities. Our processes leverage automation and advanced prioritization to streamline triage and enable rapid remediation of high-exposure findings.

The Appian CSA Assessment

In light of the evolving threat landscape, Appian has rigorously evaluated the risks and strategic guidance associated with frontier models, specifically aligning our internal assessments with findings from the Cloud Security Alliance (CSA) Mythos paper. We ensure our posture remains anchored in foundational operational rigor (e.g. systems hardening, mature vulnerability remediation, and rapid incident response), while simultaneously incorporating agentic AI technologies to modernize and accelerate our defensive capabilities.

To reinforce Appian’s approach, our security investments (based on our risk assessments) are focused on:

AI-Enhanced Secure Architecture: To ensure issues are mitigated before they reach the codebase, we are reinforcing our agentic SDLCs by integrating AI-driven tools for continuous threat modeling and architectural reviews.
Agent-Integrated Vulnerability Scanning: We have transitioned security services into agent-accessible tools that operate directly within developer environments and are strictly enforced via central code pipelines to automate remediation.
Robust Supply Chain Protection: Appian is actively strengthening our software supply chain by moving to private, vendor-managed artifact repositories and incorporating hardened components, such as Chainguard, to maintain rigorous integrity against AI-driven exploitation.

Appian’s Offensive Defense: Turning AI-Accelerated Risk into Modernization Opportunity

The greatest defense against AI-accelerated offense is a fundamental shift in application strategy. The Mythos model highlights a critical moment where organizations must move beyond defensive patching toward architectural security by default.

Legacy or “vibe” code is now unsafe at any speed.
- Why & How with Appian: The speed of vulnerability discovery (now compressed to hours) means manual custom code development and patching cycles can no longer keep pace. Appian's low-code platform eliminates vast amounts of custom code, reducing the attack surface and enforcing secure patterns by design.
Due to the insecure nature of AI vibe coding, enterprises should replace it with spec-driven development on secure platforms like Appian.
- Why & How with Appian: Relying on large language models (LLMs) to generate "vibe code" introduces new supply chain and vulnerability risks from potentially unvetted code. Appian's low-code, spec-driven approach generates standardized, secure code from certified platform components, ensuring integrity and auditability.
Enterprises need to migrate custom and legacy apps to secure-by-default platforms like Appian.
- Why & How with Appian: Legacy apps are highly susceptible to this new shift. Appian provides a secure cloud architecture leveraging AWS's scale and security controls, offering continuous updates and a mature vulnerability management program.
Secure platforms that reduce your attack surface and centralize patching and monitoring are the best way to reduce workload on security teams.
- Why & How with Appian: Moving applications to Appian Cloud shifts the burden of infrastructure security, patching (aggressive SLAs), and continuous monitoring to Appian and AWS. This drastically reduces the operational overhead and allows internal security teams to focus on core business risks.
AI Agents need the guardrails and governance of secure process orchestration that Appian provides.
- Why & How with Appian: As autonomous AI agents become pervasive, constraining their actions is critical. Appian's process orchestration provides the necessary identity-aware framework, policy enforcement, and auditability to govern AI agents, ensuring they operate within defined, secure business processes.

Customer Changes: Required Actions

The speed of AI-accelerated threats requires immediate action to solidify your foundational security posture. We recommend customers prioritize the following actions:

Accelerate Platform Updates: Promptly prioritize and schedule upgrades to the latest Appian platform releases to benefit from our continuous security enhancements and keep pace with vulnerability remediation. Reach out to Appian Support with your organization's desired posture; we recommend taking the latest release as soon as feasible for your organization. We can patch at the speed of your mission needs.
Enforce MFA for All Accounts: With the release of additional MFA features in 26.1, audit your organizational requirements, ensure alignment and reach out to Appian Support if you need assistance. We recommend strong Multi-Factor Authentication (MFA) for all accounts (Appian or otherwise) to strengthen identity controls against AI-driven social engineering and credential misuse.
Modernize on Appian Cloud: Eliminate critical attack surface by migrating all custom and legacy applications to the latest version of Appian Cloud, which offers secure-by-default architecture, centralized patching, and continuous monitoring.
Adopt New Security Capabilities: Rapidly adopt key platform security features as they become available, such as Cloud Secure Link (when available) and Log Streaming (24.4/26.4) enhancements to meet your mission needs.

Callout on Further Action: If additional, environment-specific action is required for your sites, our Solution Engineering team will reach out directly; ensure your security and admin contacts are up-to-date.

Closing Statement

Appian’s security posture is built keeping in mind the speed and scale of AI-accelerated threat discovery by frontier models. Our response strategy aligns with the industry, shifting to Zero-Trust and high-velocity operational rigor that prioritizes foundational security controls: vulnerability remediation, continuous monitoring, and continuous testing. This architectural approach is the essential alternative to risky “AI Vibe coding”; replacing ad-hoc code generation with spec-driven development using standardized, certified platform components to ensure security and auditability. Furthermore, Appian's secure process orchestration provides the necessary guardrails and governance to ensure pervasive AI agents operate securely within defined business processes, using identity-aware access and policy enforcement. Ultimately, our platform enables customers to quickly modernize legacy applications—which are highly susceptible to this new threat—on a secure, continuously updated architecture. This accelerated threat landscape requires a joint effort.

To immediately strengthen your defenses and keep pace with AI-accelerated threats, we urge you to review and implement the Required Actions detailed above: Accelerate Platform Updates, Enforce MFA for All Accounts, Modernize on Appian Cloud, and Adopt New Security Capabilities.

This article applies to all supported versions of Appian.

Last reviewed: May 27, 2026

KB-2384 Appian's Response to AI-Accelerated Threats (Mythos, Daybreak, MDASH)

Kaushal Patel — Wed, 27 May 2026 16:48:50 GMT

Revision 1 posted to Appian Knowledge Base by Kaushal Patel on 5/27/2026 4:48:50 PM

Executive Summary

What is Mythos?

What is Daybreak?

What is MDASH?

Appian’s Perspective

We are actively engaged using tools available to us today, and take the opportunity that AI presents very seriously on behalf of Appian, you (our customers), and your customers. More on this below.

Appian’s Position

Secure-by-Design Infrastructure

Differentiated Platform Architecture

The Appian Platform architecture is fundamentally designed to reduce inherent risk and exposure:

Zero-Trust: Appian's architecture is built on Zero Trust principles: never trust, assume breach, and verify every access request. This is implemented via a multi-control point lattice, shifting defenses from static perimeters to focus on users, assets, and resources. Core components include strong identity, device health, continuous re-authentication, hyper least privilege, and encryption everywhere. This resilient platform design provides consistent security regardless of user location or data sensitivity.
Identity-Aware Access: All customer applications and data interactions are governed by a robust, fine-grained identity and access framework.
Multi-Tenant Controls: Strong logical separation is enforced across all multi-tenant environments, isolating customer data and reducing the potential impact of a single vulnerability.
Policy Enforcement and Auditability: The platform enforces strict security policies at every layer, providing comprehensive audit trails that enhance detection and response capabilities.

Integrated Security Development: We leverage both deterministic and AI-assisted/agentic tools directly into our continuous integration pipeline to automatically flag and help developers remediate vulnerabilities before code is promoted. We are also adapting the frequency of AI-assisted secure code reviews for our entire code-base to proactively hunt vulnerabilities. Continuous 3rd party White-Hat Hackers and penetration testing are used to further enhance our posture.
Our active investments in GenAI-driven security ensure continuous protection at the speed of development:
- AI-Powered Secure Design: We are augmenting security tools with additional AI-powered tools for architecture review and threat modeling to identify and fix flaws continuously in the agentic SDLCs, preventing issues before they are coded.
- Agentic Code Scanning: Security services in our SDLC have already been created as agent accessible tools to scan and remediate vulnerabilities directly inside developer environment tooling) and centrally enforced in code pipelines.
- Supply Chain Hardening: We are seeking additional hardened components similar to our use of Chainguard. We are migrating to private, vendor-managed third-party libraries and in our centralized artifact repository which governs all components, ensuring the integrity and provenance of our software supply chain against AI-accelerated attacks.

Mature Vulnerability Management Program

Appian maintains a mature, risk-based vulnerability management program that adheres to industry standards and regulatory expectations:

Prioritization and Remediation: We leverage systems like CISA’s Known Exploited Vulnerabilities (KEV) database, and plan to include additional exploitability and reachability metrics to prioritize remediation based on real-world threat exposure, ensuring a focus on the most critical risks.
Operational Rigor: Appian is committed to aggressive patching SLAs and maintaining Plan of Action and Milestones (POA&M) discipline. We are continuously improving our ability to rapidly deploy patches, specifically to meet the accelerated timelines suggested by AI-enabled offense.
Supply Chain Security: To proactively counter supply chain risks, Appian is migrating to private, curated third-party libraries for components, ensuring all dependencies are current, patched, and malware-free. We partner with industry leading firms on pre-hardened and pre-patched assets in our supply chain where possible.

Scaling Vulnerability Management: We are preparing for an order-of-magnitude increase in discovered vulnerabilities. Our processes leverage automation and advanced prioritization to streamline triage and enable rapid remediation of high-exposure findings.

The Appian CSA Assessment

To reinforce Appian’s approach, our security investments (based on our risk assessments) are focused on:

AI-Enhanced Secure Architecture: To ensure issues are mitigated before they reach the codebase, we are reinforcing our agentic SDLCs by integrating AI-driven tools for continuous threat modeling and architectural reviews.
Agent-Integrated Vulnerability Scanning: We have transitioned security services into agent-accessible tools that operate directly within developer environments and are strictly enforced via central code pipelines to automate remediation.
Robust Supply Chain Protection: Appian is actively strengthening our software supply chain by moving to private, vendor-managed artifact repositories and incorporating hardened components, such as Chainguard, to maintain rigorous integrity against AI-driven exploitation.

Appian’s Offensive Defense: Turning AI-Accelerated Risk into Modernization Opportunity

Legacy or “vibe” code is now unsafe at any speed.
- Why & How with Appian: The speed of vulnerability discovery (now compressed to hours) means manual custom code development and patching cycles can no longer keep pace. Appian's low-code platform eliminates vast amounts of custom code, reducing the attack surface and enforcing secure patterns by design.
Due to the insecure nature of AI vibe coding, enterprises should replace it with spec-driven development on secure platforms like Appian.
- Why & How with Appian: Relying on large language models (LLMs) to generate "vibe code" introduces new supply chain and vulnerability risks from potentially unvetted code. Appian's low-code, spec-driven approach generates standardized, secure code from certified platform components, ensuring integrity and auditability.
Enterprises need to migrate custom and legacy apps to secure-by-default platforms like Appian.
- Why & How with Appian: Legacy apps are highly susceptible to this new shift. Appian provides a secure cloud architecture leveraging AWS's scale and security controls, offering continuous updates and a mature vulnerability management program.
Secure platforms that reduce your attack surface and centralize patching and monitoring are the best way to reduce workload on security teams.
- Why & How with Appian: Moving applications to Appian Cloud shifts the burden of infrastructure security, patching (aggressive SLAs), and continuous monitoring to Appian and AWS. This drastically reduces the operational overhead and allows internal security teams to focus on core business risks.
AI Agents need the guardrails and governance of secure process orchestration that Appian provides.
- Why & How with Appian: As autonomous AI agents become pervasive, constraining their actions is critical. Appian's process orchestration provides the necessary identity-aware framework, policy enforcement, and auditability to govern AI agents, ensuring they operate within defined, secure business processes.

Customer Changes: Required Actions

The speed of AI-accelerated threats requires immediate action to solidify your foundational security posture. We recommend customers prioritize the following actions:

Accelerate Platform Updates: Promptly prioritize and schedule upgrades to the latest Appian platform releases to benefit from our continuous security enhancements and keep pace with vulnerability remediation. Reach out to Appian Support with your organization's desired posture; we recommend taking the latest release as soon as feasible for your organization. We can patch at the speed of your mission needs.
Enforce MFA for All Accounts: With the release of additional MFA features in 26.1, audit your organizational requirements, ensure alignment and reach out to Appian Support if you need assistance. We recommend strong Multi-Factor Authentication (MFA) for all accounts (Appian or otherwise) to strengthen identity controls against AI-driven social engineering and credential misuse.
Modernize on Appian Cloud: Eliminate critical attack surface by migrating all custom and legacy applications to the latest version of Appian Cloud, which offers secure-by-default architecture, centralized patching, and continuous monitoring.
Adopt New Security Capabilities: Rapidly adopt key platform security features as they become available, such as Cloud Secure Link (when available) and Log Streaming (24.4/26.4) enhancements to meet your mission needs.

Closing Statement

This article applies to all supported versions of Appian.

Last reviewed: May 27, 2026

[DRAFT SUPP-1654] Plugin Review & Security Scanning FAQ

Ryan Good — Wed, 27 May 2026 15:36:59 GMT

Revision 5 posted to Appian Knowledge Base by Ryan Good on 5/27/2026 3:36:59 PM

All plugins submitted to Appian for use on Appian Cloud require review and approval. This article aims to answer common questions about the plugin review process.

For more information on plugin and AppMarket policies, refer to the AppMarket Submission Policies documentation and the AppMarket Submissions Agreement.

Table of Contents:

How are plugin security reviews performed?
What specific tooling is used?
How often are reviews performed?
What happens to plugins that are flagged by security scans?
Can Appian provide the scan results?
What happens to plugins that are flagged by security scans?
How long do I have to remediate a finding in my plugin?
My plugin submission was previously approved. Why is my latest update not approved?
I need to use my plugin on Appian Cloud ASAP. Can I bypass security review temporarily?

How are plugin security reviews performed?

What specific tooling is used?

How often are reviews performed?

Reviews are always performed upon plugin submission. Post-approval, additional security reviews are performed regularly.
Appian reserves the right to perform security reviews at any time.

Do security reviews apply to private plugins?

Yes. As stated in the AppMarket Submission Policies, All plug-ins, whether intended for public use on the AppMarket or private use within an organization, must receive approval before deployment.

Can Appian provide the scan results?

Appian does not publish or share the results of security scans.
Plugin authors are notified directly when one of their submissions is flagged by a security scan.

What happens to plugins that are flagged by security scans?

How long do I have to remediate a finding in my plugin?

Appian will provide a timeline for remediation when notifying you of a finding.
Appian reserves the right to modify plug-in remediation timelines at any time.

My plugin submission was previously approved. Why is my latest update not approved?

I need to use my plugin on Appian Cloud ASAP. Can I bypass security review temporarily?

Affected Versions

This article applies to all versions of Appian.

Last Reviewed: May 2026

Tags: FAQ, plugins

KB-2383 Interactive SAIL Examples in Appian Documentation Fail to Execute

pauline.delacruz — Tue, 26 May 2026 16:01:08 GMT

Current Revision posted to Appian Knowledge Base by pauline.delacruz on 5/26/2026 4:01:08 PM

Symptoms

Interactive SAIL expression examples embedded in Appian documentation pages fail to execute. The browser displays the following error message:

The connection is blocked because it was initiated by a public page to connect to devices or servers on your local network.

This issue occurs in networks where the AWS API Gateway endpoint used by the documentation resolves to a private IP address.

Cause

Appian documentation pages use an AWS API Gateway endpoint with the domain *.execute-api.us-east-1.amazonaws.com to support execution of SAIL expressions. In enterprise networks AWS service endpoints may resolve to a private IP address. Modern browsers block requests where the originating page is treated as public and the target endpoint resolves to a private or local IP address. This is intentional browser behavior designed to prevent DNS rebinding and local network attacks.

Action

This is a known limitation that affects enterprise networks with private AWS networking configurations. Appian has added an enhancement to the documentation backlog to address this issue (Reference ticket: LCP-49998). No estimated time of availability is currently provided for this enhancement.

Workaround

Organizations may allow *.execute-api.us-east-1.amazonaws.com domains to resolve using public DNS controls to ensure the page loads properly.

Affected Versions

This article applies to all versions of Appian.

Last Reviewed: May 2026

Tags: web browser, infrastructure, Cloud

[DRAFT SUPP-2591] Log ingestion pipelines fail for login-audit.csv after upgrading to Appian 25.4

pauline.delacruz — Wed, 20 May 2026 20:12:41 GMT

Revision 13 posted to Appian Knowledge Base by pauline.delacruz on 5/20/2026 8:12:41 PM

Symptoms

As a result, administrators may experience a temporary loss of login audit data visibility in downstream reporting stores, or trigger internal security/IT alerts due to these ingestion job failures.

Cause

This issue is caused by schema changes introduced in Appian 25.4 to support the new "Multi-Factor Authentication: Authenticator Apps" feature.

Pipelines relying on headerless parsing or strict positional index mapping will fail due to two structural modifications:

Inclusion of Headers: Row 1 of login-audit.csv now contains column headers. Historically, this file was headerless.
New MFA Tracking Column: A new column was appended to the log to track native MFA events.
- In Appian 25.4, this column was initially introduced as MFA User.
- In Appian Hotfix 25.4.371.0, this column was renamed to MFA Authenticated and its behavior was refined to accurately distinguish genuine Appian MFA events from SSO/LDAP authentications.
- Note: true indicates successful authentication using Appian native MFA, while false indicates external authentication (SSO/LDAP), primary authentication failure, or MFA not being enabled.

Strict positional parsing of the login-audit.csv file without accounting for the newly added header row is no longer a supported ingestion approach.

For more information about login-audit.csv, refer to Logging

Action

To resolve this issue and prevent future disruptions, log ingestion scripts and parsers must be updated:

Account for the Header Row: Update ingestion scripts to ignore the first row as data, treating it instead as the schema definition.
Update Parsing Logic: Switch from positional indexing to header-based mapping (e.g., map by the exact header string MFA Authenticated). This guarantees pipeline stability even if column orders change in future releases.

Affected Versions

This article applies to Appian 25.4 and later.

Last Reviewed: May 2026

Tags: authentication

[DRAFT SUPP-2640] Interactive SAIL Examples in Appian Documentation Fail to Execute

pauline.delacruz — Wed, 20 May 2026 19:06:41 GMT

Revision 7 posted to Appian Knowledge Base by pauline.delacruz on 5/20/2026 7:06:41 PM

Symptoms

Interactive SAIL expression examples embedded in Appian documentation pages fail to execute. The browser displays the following error message:

The connection is blocked because it was initiated by a public page to connect to devices or servers on your local network.

This issue occurs in networks where the AWS API Gateway endpoint used by the documentation resolves to a private IP address.

Cause

Action

Workaround

Organizations may allow *.execute-api.us-east-1.amazonaws.com domains to resolve using public DNS controls to ensure the page loads properly.

Affected Versions

This article applies to all versions of Appian.

Last Reviewed: May 2026

Tags: web browser, infrastructure, Cloud

[DRAFT SUPP-2640] Interactive SAIL Examples in Appian Documentation Fail to Execute

Zack Mateja — Wed, 20 May 2026 18:58:57 GMT

Revision 6 posted to Appian Knowledge Base by Zack Mateja on 5/20/2026 6:58:57 PM

Symptoms

Interactive SAIL expression examples embedded in Appian documentation pages fail to execute. The browser displays the following error message:

The connection is blocked because it was initiated by a public page to connect to devices or servers on your local network.

This issue occurs in networks where the AWS API Gateway endpoint used by the documentation resolves to a private IP address.

Cause

Appian documentation pages use an AWS API Gateway endpoint with the domain *.execute-api.us-east-1.amazonaws.com to support execution of SAIL expressions. In enterprise networks AWS service endpoints may resolve to a private IP address. Modern browsers block requests where the originating page is treated as public and the target endpoint resolves to a private or local IP address. This is intentional browser behavior designed to prevent DNS rebinding and local network attacks.

Action

Workaround

Organizations may allow *.execute-api.us-east-1.amazonaws.com domains to resolve using public DNS controls to ensure the page loads properly.

Last Reviewed: May 2026

Tags: web browser, infrastructure, Cloud

[DRAFT SUPP-2640] Interactive SAIL Examples in Appian Documentation Fail to Execute

Zack Mateja — Wed, 20 May 2026 15:36:33 GMT

Revision 5 posted to Appian Knowledge Base by Zack Mateja on 5/20/2026 3:36:33 PM

Symptoms

Interactive SAIL expression examples embedded in Appian documentation pages fail to execute. The browser displays the following error message:

The connection is blocked because it was initiated by a public page to connect to devices or servers on your local network.

This issue occurs in networks where the AWS API Gateway endpoint used by the documentation resolves to a private IP address.

Cause

Action

Workaround

Organizations may allow *.execute-api.us-east-1.amazonaws.com domains to resolve using public DNS controls to ensure the page loads properly.

Last Reviewed: May 2026

Tags: web browser, infrastructure, Cloud

[DRAFT SUPP-2640] Using Interactive SAIL Boxes in Appian Documentation

Zack Mateja — Wed, 20 May 2026 15:35:59 GMT

Revision 4 posted to Appian Knowledge Base by Zack Mateja on 5/20/2026 3:35:59 PM

Interactive SAIL Examples in Appian Documentation Fail to Execute

Symptoms

Interactive SAIL expression examples embedded in Appian documentation pages fail to execute. The browser displays the following error message:

The connection is blocked because it was initiated by a public page to connect to devices or servers on your local network.

This issue occurs in networks where the AWS API Gateway endpoint used by the documentation resolves to a private IP address.

Cause

Action

Workaround

Organizations may allow *.execute-api.us-east-1.amazonaws.com domains to resolve using public DNS controls to ensure the page loads properly.

Last Reviewed: May 2026

Tags: web browser, infrastructure, Cloud

[DRAFT SUPP-2640] Using Interactive SAIL Boxes in Appian Documentation

Zack Mateja — Wed, 20 May 2026 15:35:42 GMT

Revision 3 posted to Appian Knowledge Base by Zack Mateja on 5/20/2026 3:35:42 PM

Interactive SAIL Examples in Appian Documentation Fail to Execute

Symptoms

Interactive SAIL expression examples embedded in Appian documentation pages fail to execute. The browser displays the following error message:

The connection is blocked because it was initiated by a public page to connect to devices or servers on your local network.

This issue occurs in networks where the AWS API Gateway endpoint used by the documentation resolves to a private IP address.

Cause

Action

Workaround

Organizations may allow *.execute-api.us-east-1.amazonaws.com domains to resolve using public DNS controls to ensure the page loads properly.

Preventative Actions

Be aware that interactive SAIL execution examples in Appian documentation rely on direct client-side calls to *.execute-api.amazonaws.com. These examples may fail in environments where those domains resolve privately or are blocked by the browser due to enterprise DNS and security configurations.

Last Reviewed: May 2026

Tags: web browser, infrastructure, Cloud

[DRAFT SUPP-2640] Using Interactive SAIL Boxes in Appian Documentation

Zack Mateja — Wed, 20 May 2026 15:35:09 GMT

Revision 2 posted to Appian Knowledge Base by Zack Mateja on 5/20/2026 3:35:09 PM

Interactive SAIL Examples in Appian Documentation Fail to Execute

Symptoms

Interactive SAIL expression examples embedded in Appian documentation pages fail to execute. The browser displays the following error message:

The connection is blocked because it was initiated by a public page to connect to devices or servers on your local network.

This issue occurs in networks where the AWS API Gateway endpoint used by the documentation resolves to a private IP address.

Cause

Action

This is a known limitation that affects enterprise networkswith private AWS networking configurations. Appian has added an enhancement to the documentation backlog to address this issue (Reference ticket: LCP-49998). No estimated time of availability is currently provided for this enhancement.

Workaround

Organizations may allow *.execute-api.us-east-1.amazonaws.com domains to resolve using public DNS controls to ensure the page loads properly.

Preventative Actions

Last Reviewed: May 2026

Tags: web browser, infrastructure, Cloud

[DRAFT SUPP-1654] Plugin Review & Security Scanning FAQ

Daniel DeVeau — Wed, 20 May 2026 14:15:38 GMT

Revision 4 posted to Appian Knowledge Base by Daniel DeVeau on 5/20/2026 2:15:38 PM

All plugins submitted to Appian for use on Appian Cloud require review and approval. This article aims to answer common questions about the plugin review process.

For more information on plugin and AppMarket policies, refer to the AppMarket Submission Policies documentation and the AppMarket Submissions Agreement.

Table of Contents:

How are plugin security reviews performed?

What specific tooling is used?

How often are reviews performed?

What happens to plugins that are flagged by security scans?

Can Appian provide the scan results?

What happens to plugins that are flagged by security scans?

How long do I have to remediate a finding in my plugin?

My plugin submission was previously approved. Why is my latest update not approved?

I need to use my plugin on Appian Cloud ASAP. Can I bypass security review temporarily?

How are plugin security reviews performed?

What specific tooling is used?

How often are reviews performed?

Reviews are always performed upon plugin submission. Post-approval, additional security reviews are performed regularly.
Appian reserves the right to perform security reviews at any time.

Do security reviews apply to private plugins?

Yes. As stated in the AppMarket Submission Policies, All plug-ins, whether intended for public use on the AppMarket or private use within an organization, must receive approval before deployment.

Can Appian provide the scan results?

Appian does not publish or share the results of security scans.
Plugin authors are notified directly when one of their submissions is flagged by a security scan.

What happens to plugins that are flagged by security scans?

How long do I have to remediate a finding in my plugin?

Appian will provide a timeline for remediation when notifying you of a finding.
Appian reserves the right to modify plug-in remediation timelines at any time.

My plugin submission was previously approved. Why is my latest update not approved?

I need to use my plugin on Appian Cloud ASAP. Can I bypass security review temporarily?

Affected Versions

This article applies to all versions of Appian.

Last Reviewed: May 2026

Tags: FAQ, plugins

[DRAFT SUPP-1654] Plugin Review & Security Scanning FAQ

Daniel DeVeau — Wed, 20 May 2026 14:12:16 GMT

Revision 3 posted to Appian Knowledge Base by Daniel DeVeau on 5/20/2026 2:12:16 PM

All plugins submitted to Appian for use on Appian Cloud require review and approval. This article aims to answer common questions about the plugin review process.

For more information on plugin and AppMarket policies, refer to the AppMarket Submission Policies documentation and the AppMarket Submissions Agreement.

Table of Contents:

How are plugin security reviews performed?

What specific tooling is used?

How often are reviews performed?

Can Appian provide the scan results?

What happens to plugins that are flagged by security scans?

How long do I have to remediate a finding in my plugin?

My plugin submission was previously approved. Why is my latest update not approved?

I need to use my plugin on Appian Cloud ASAP. Can I bypass security review temporarily?

How are plugin security reviews performed?

What specific tooling is used?

How often are reviews performed?

Reviews are always performed upon plugin submission. Post-approval, additional security reviews are performed regularly.
Appian reserves the right to perform security reviews at any time.

Do security reviews apply to private plugins?

Yes. As stated in the AppMarket Submission Policies, All plug-ins, whether intended for public use on the AppMarket or private use within an organization, must receive approval before deployment.

Can Appian provide the scan results?

Appian does not publish or share the results of security scans.
Plugin authors are notified directly when one of their submissions is flagged by a security scan.

What happens to plugins that are flagged by security scans?

How long do I have to remediate a finding in my plugin?

Appian will provide a timeline for remediation when notifying you of a finding.
Appian reserves the right to modify plug-in remediation timelines at any time.

My plugin submission was previously approved. Why is my latest update not approved?

I need to use my plugin on Appian Cloud ASAP. Can I bypass security review temporarily?

Affected Versions

This article applies to all versions of Appian.

Last Reviewed: May 2026

Tags: FAQ, plugins

[DRAFT SUPP-1654] Plugin Review & Security Scanning FAQ

Daniel DeVeau — Wed, 20 May 2026 14:07:51 GMT

Revision 2 posted to Appian Knowledge Base by Daniel DeVeau on 5/20/2026 2:07:51 PM

All plugins submitted to Appian for use on Appian Cloud require review and approval. This article aims to answer common questions about the plugin review process.

For more information on plugin and AppMarket policies, refer to the AppMarket Submission Policies documentation and the AppMarket Submissions Agreement.

Table of Contents:

How are plugin security reviews performed?

What specific tooling is used?

How often are reviews performed?

Can Appian provide the scan results?

What happens to plugins that are flagged by security scans?

How long do I have to remediate a finding in my plugin?

My plugin submission was previously approved. Why is my latest update not approved?

I need to use my plugin on Appian Cloud ASAP. Can I bypass security review temporarily?

How are plugin security reviews performed?

Security scanning is first performed during the submission of new and updated plugins to Appian.

Subsequent reviews are also performed on a routine basis after initial approval.

Scans such as Static Application Security Testing (SAST), Software composition analysis (SCA), and other security related checks are in place.

What specific tooling is used?

Appian utilizes custom tooling, open source software, and commercial off the shelf software to perform the automated security scanning.

Appian does not publish the specific software used to review plugins.

How often are reviews performed?

Reviews are always performed upon plugin submission. Post-approval, additional security reviews are performed regularly .

Appian reserves the right to perform security reviews at any time.

Can Appian provide the scan results?

Appian does not publish or share the results of security scans.

Plugin authors are notified directly when one of their submissions is flagged by a security scan.

Do security reviews apply to private plugins?

Yes. As stated in the AppMarket Submission Policies, All plug-ins, whether intended for public use on the AppMarket or private use within an organization, must receive approval before deployment.

What happens to plugins that are flagged by security scans?

Plugin authors are notified directly when one of their submissions is flagged by a security scan.

Plugins which are not updated may be removed from the AppMarket.

Appian reserves the right to reject or stop hosting plug-ins at any time.

How long do I have to remediate a finding in my plugin?

Appian will provide a timeline for remediation when notifying you of a finding.

Appian reserves the right to modify plug-in remediation timelines at any time.

My plugin submission was previously approved. Why is my latest update not approved?

Every submitted version of a plugin is reviewed in full.

Approval of a plugin does not guarantee approval of subsequent versions.

Appian reserves the right to modify plugin security policies at any time.

I need to use my plugin on Appian Cloud ASAP. Can I bypass security review temporarily?

Plugin submissions cannot bypass security review; only fully approved submissions can be deployed on Appian Cloud.

If a plug-in requires expedited review, please include that context and justification in the submission.

If you subscribe to a Signature Appian Success Plan, let your Lead Engineer know of your urgent request.

Affected Versions

This article applies to all versions of Appian.

Last Reviewed: May 2026

Tags: FAQ, plugins

[DRAFT SUPP-2591] Log ingestion pipelines fail for login-audit.csv after upgrading to Appian 25.4

cesar.gilalonso — Tue, 19 May 2026 08:58:41 GMT

Revision 12 posted to Appian Knowledge Base by cesar.gilalonso on 5/19/2026 8:58:41 AM

Symptoms

As a result, administrators may experience a temporary loss of login audit data visibility in downstream reporting stores, or trigger internal security/IT alerts due to these ingestion job failures.

Cause

This issue is caused by schema changes introduced in Appian 25.4 to support the new "Multi-Factor Authentication: Authenticator Apps" feature.

Pipelines relying on headerless parsing or strict positional index mapping will fail due to two structural modifications:

Inclusion of Headers: Row 1 of login-audit.csv now contains column headers. Historically, this file was headerless.
New MFA Tracking Column: A new column was appended to the log to track native MFA events.
- In Appian 25.4, this column was initially introduced as MFA User.
- In Appian Hotfix 25.4.371.0, this column was renamed to MFA Authenticated and its behavior was refined to accurately distinguish genuine Appian MFA events from SSO/LDAP authentications.
- Note: true indicates successful authentication using Appian native MFA, while false indicates external authentication (SSO/LDAP), primary authentication failure, or MFA not being enabled.

Strict positional parsing of the login-audit.csv file without accounting for the newly added header row is no longer a supported ingestion approach.

For more information about login-audit.csv, refer to Logging

Action

To resolve this issue and prevent future disruptions, log ingestion scripts and parsers must be updated:

Account for the Header Row: Update ingestion scripts to ignore the first row as data, treating it instead as the schema definition.
Update Parsing Logic: Switch from positional indexing to header-based mapping (e.g., map by the exact header string MFA Authenticated). This guarantees pipeline stability even if column orders change in future releases.

Affected Versions

This article applies to Appian 25.4 and later.

Last Reviewed: May 2026

Tags: authentication

[DRAFT SUPP-2591] Log ingestion pipelines fail for login-audit.csv after upgrading to Appian 25.4

cesar.gilalonso — Tue, 19 May 2026 08:57:53 GMT

Revision 11 posted to Appian Knowledge Base by cesar.gilalonso on 5/19/2026 8:57:53 AM

Symptoms

As a result, administrators may experience a temporary loss of login audit data visibility in downstream reporting stores, or trigger internal security/IT alerts due to these ingestion job failures.

Cause

This issue is caused by schema changes introduced in Appian 25.4 to support the new "Multi-Factor Authentication: Authenticator Apps" feature.

Pipelines relying on headerless parsing or strict positional index mapping will fail due to two structural modifications:

Inclusion of Headers: Row 1 of login-audit.csv now contains column headers. Historically, this file was headerless.
New MFA Tracking Column: A new column was appended to the log to track native MFA events.
- In Appian 25.4, this column was initially introduced as MFA User.
- In Appian Hotfix 25.4.371.0, this column was renamed to MFA Authenticated and its behavior was refined to accurately distinguish genuine Appian MFA events from SSO/LDAP authentications.
- Note: true indicates successful authentication using Appian native MFA, while false indicates external authentication (SSO/LDAP), primary authentication failure, or MFA not being enabled.

Strict positional parsing of the login-audit.csv file without accounting for the newly added header row is no longer a supported ingestion approach.

For more information about login-audit.csv, refer to Logging

Action

To resolve this issue and prevent future disruptions, log ingestion scripts and parsers must be updated:

Account for the Header Row: Update ingestion scripts to ignore the first row as data, treating it instead as the schema definition.
Update Parsing Logic: Switch from positional indexing to header-based mapping (e.g., map by the exact header string MFA Authenticated). This guarantees pipeline stability even if column orders change in future releases.

Affected Versions

This article applies to Appian 25.4 and later.

Tags: authentication