This document describes the security architecture and posture of the Orient AXLR8 & ACTV8 Eclipse plugin, written for technical reviewers at prospective customers. It is a transparent, self-attested account of the security controls, data flows, and operational boundaries customers should be aware of.
This document is not a third-party audit, penetration-test report, certification statement, or warranty. The intent is to provide clear, practical, and verifiable security information without relying on generic marketing claims.
1. Executive summary
Orient AXLR8 & ACTV8 is an Eclipse plugin that augments ABAP development against SAP ADT REST endpoints. It runs entirely inside the developer's Eclipse IDE on the developer's workstation. There is no plugin-side cloud service, no telemetry beacon, and no license check that calls home.
SAP credentials remain on the developer's machine except when used for the developer's outbound authenticated connection to the customer's own SAP system. All SAP activity continues to operate through the customer's SAP authorization model.
The plugin can invoke large-language-model providers such as OpenAI, Anthropic, Google Gemini, or local model options for code generation and AI-assisted fix workflows. When a cloud AI provider is selected, prompt content and relevant source excerpts submitted by the user are transmitted to that provider under the user's configured API key. The selected provider's data-handling terms therefore form part of the customer's overall security assessment.
The product includes workflow safeguards for AI-assisted ABAP development, including destructive-operation checks, controlled AI-fix retry handling, hardened XML parsing on SAP deployment responses, and local audit visibility for AI-generated or AI-modified artifacts.
2. Architecture & trust boundaries
The plugin loads inside the customer's Eclipse installation. It has no privileged backend, no shared multi-tenant runtime, and no operator-side hosted service. From a trust-boundary perspective, the plugin executes in the same user account, workstation context, and network environment as Eclipse itself.
Customer-Controlled Plugin Flow
The plugin runs inside the customer-controlled developer workstation. The dotted green path shows where secrets are read at runtime: from Eclipse Secure Storage into the runtime flow used by the configured systems.
Eclipse IDE
Main development environment where the plugin runs.
Orient AXLR8 / ACTV8 plugin
Runs inside Eclipse IDE.
Eclipse Secure Storage
Secrets read at runtime.
Customer SAP
ADT REST APIs
customer-owned
AI provider
cloud or local
customer-selected
At runtime, the plugin communicates with the customer's configured SAP system and the customer-selected AI provider. There is no third destination for development workflow data. The plugin does not enumerate customer machines, transmit usage analytics, collect prompts, collect source code, or report developer activity back to OrientCDS infrastructure.
3. Data flow: where customer data goes and does not go
| Data class | Persistent storage | In-flight destinations |
|---|---|---|
| SAP credentials | Eclipse Secure Storage wherever available | Sent only to the user-configured SAP system over TLS |
| AI provider API keys | Eclipse Secure Storage wherever available | Sent only to the corresponding AI provider endpoint over TLS |
| ABAP source code, prompts, FSDs, and pasted snippets | Customer's local workspace and customer-controlled environment | Sent to the selected AI provider when the user requests AI generation, review, or fix assistance |
| Generated ABAP artifacts | Local workspace and the customer's SAP system after deployment | Sent to the customer-configured SAP system during deployment |
| SAP deployment requests | Local plugin runtime | Sent to the customer SAP system through SAP ADT APIs |
| Workspace context used for AI assistance | Local Eclipse state area | Used locally unless included in a user-requested AI operation |
| AI audit metadata | Local Eclipse state area | Not sent to OrientCDS infrastructure |
| Telemetry and usage analytics | Not collected. The plugin does not emit telemetry, crash reports, prompt logs, source-code logs, or usage analytics to OrientCDS. | |
4. Security controls
4.1 Destructive-operation guard on AI-emitted code
Before AI-generated ABAP artifacts are uploaded to SAP, the source is checked for destructive database operations that target tables outside the customer's permitted namespace. These checks are designed to reduce the risk of unsafe AI output being deployed without developer review.
The guard is aware of ABAP comments and literal text so that normal comments or text strings do not accidentally bypass the intended checks. If a risky operation is detected, deployment is blocked and a clear error is shown to the developer.
A separate safeguard applies to natural-language table browsing. The query path is restricted so that it cannot be turned into a generic destructive SQL execution surface.
4.2 Controlled AI Fix retry workflow
AI-assisted fixes are used only in a controlled workflow. Not every deployment failure is sent to AI. Failures such as authentication issues, locking issues, authorization issues, unsupported endpoints, and unknown errors are treated as hard failures and are not automatically routed into an AI-fix loop.
- Only eligible syntax or deployment-related failures can enter the AI Fix workflow.
- Retry attempts are limited.
- If the type of failure changes across retries, the AI Fix workflow is stopped.
This helps prevent an AI-generated correction from masking the original issue or introducing a new class of problem during repeated fix attempts.
4.3 XML parser hardening
XML parsing on the SAP deployment path uses hardened parser configuration. External entity expansion, document type declarations, XInclude processing, and external parameter entities are disabled where applicable.
This defensive configuration reduces the risk of XML-related parsing attacks in deployment response handling. SAP endpoints are expected to return well-formed ADT responses, but the plugin still applies defensive parser settings as a security precaution.
4.4 Local AI audit visibility
AI-generated or AI-modified artifacts can be tracked locally in the customer's Eclipse environment. Audit metadata can include the object name, object type, timestamp, AI action, capability used, review status, and a short code fingerprint to help identify subsequent manual edits.
This gives customer teams a practical way to review AI-assisted development activity in the local workspace without relying on developer memory or external telemetry.
4.5 SAP ADT session discipline
SAP ADT requests follow SAP's stateful-session model. The plugin uses the configured SAP connection, obtains the required session information, reuses SAP-issued cookies during the session, and tears down the session when appropriate.
A fresh deploy session is established for artifact deployment workflows so that a failure in one artifact does not corrupt the deployment state of the next artifact.
4.6 Credential storage
SAP credentials and AI provider API keys are stored using Eclipse Secure Storage wherever available. Credentials are read at runtime only when needed to authenticate with the configured SAP system or selected AI provider.
Credentials are not written to audit metadata, workspace output, generated artifacts, or OrientCDS infrastructure.
4.7 Local-only license validation
License validation is performed locally. The validation process does not contact a remote OrientCDS service during normal plugin operation.
This keeps the development workflow independent of an OrientCDS-hosted backend and avoids introducing a separate operational dependency into the customer's SAP development environment.
5. Shared responsibility
The plugin is one component of the customer's overall ABAP development security posture. The following areas remain under customer or operator responsibility:
- AI provider choice and data-handling terms. When a cloud AI provider is selected, prompts and relevant code context may be transmitted to that provider. Customers should evaluate the selected provider's data-processing, retention, and compliance terms.
- SAP authorization model. The plugin acts as the logged-in developer. It cannot grant access the developer does not already have. SAP roles and permissions remain the control point for restricting activation, transport activity, object changes, and deployment.
- Eclipse hardening. The plugin inherits the security posture of the developer's Eclipse installation, including JVM version, secure storage configuration, update channel controls, and workstation hardening.
- Network controls. Outbound TLS access to the chosen AI provider must be allowed by the customer's network policy. Customers with strict no-egress requirements may configure local AI runtime options where supported.