IT & Security

# Architect Language Tools

Trust model, distribution controls, and security posture
for IT and security reviewers

This deck answers the question: "Is it safe to allow this tooling into our environment?" The answer is yes — and this presentation explains precisely why.
What It Is

## A static analyser — nothing more

The Architect Language Tools project is a static code analyser for a proprietary scripting language.

It reads Architect source files (plain text), tokenises them, and produces a list of diagnostic messages describing issues found. It does this the same way ESLint analyses JavaScript, or a compiler emits warnings before producing an executable.

The closest analogy: a spell-checker for code. It reads the document and reports problems. It does not run the document.

Does not execute Architect code. The tooling tokenises text. It never invokes the Architect runtime.

Does not connect to any database or system. No network calls, no database connections, no API calls — at any point during validation.

Does not modify source files. Output is a read-only JSON report. Quick fixes in the IDE require explicit developer action — nothing is changed automatically.

No telemetry or external communication. The tooling has no update checker, usage tracking, or outbound calls of any kind.

Lead with the "what it can't do" list. This is usually the fastest way to address the concerns of a security-focused audience.
Components

## Two components — two distinct risk profiles

#### Component 1: VS Code Extension

- Runs on the developer's workstation inside VS Code
- Has the same OS-level permissions as the developer
- Reads Architect source files in the open workspace
- Writes nothing — produces in-editor annotations only
- Source code is internal and fully auditable before distribution

#### Component 2: Headless CLI

- Runs inside Azure Pipelines build agents — not on production servers
- Read access to the source checkout directory only
- Writes a JSON report to a staging directory
- Exits with a non-zero code if validation thresholds are breached
- No access to production database, runtime, or file shares

The validation engine (`@acurity/core`) is the same in both components. Reviewing the core once covers the logic used in both surfaces.

The two-component structure means the risk surface is well-defined. Each component has a clear boundary.
IDE Extension — Controls

## Controlling the VS Code extension

#### Private VSIX distribution — not the public Marketplace

The extension is distributed as a `.vsix` file via an internal channel (internal file share or Azure Artifacts Universal Package). It is never published to the public VS Code Marketplace. Only IT-provisioned installations are possible.

#### Marketplace allowlist (Azure AD + Intune)

VS Code's extension marketplace can be restricted via policy so that only approved extension IDs can be installed. This prevents developers from bypassing IT by installing the extension from the public Marketplace.

#### VS Code Restricted Mode / Workspace Trust

VS Code 1.75+ supports workspace trust policies enforceable via Group Policy. Extensions requiring elevated capabilities must be explicitly trusted by the user.

#### Internal source — full audit before each release

Because the source is maintained internally, the security team can review every release before the VSIX is distributed. This is a significant advantage over trusting third-party Marketplace extensions.

The private VSIX route is the most important control. It means IT controls the install, not individual developers.
CLI in CI/CD — Controls

## Pipeline agent permission model

The CLI runs inside an Azure Pipelines agent — not on the production Architect runtime. The recommended agent permission model:

Resource | Access level | Rationale
--- | --- | ---
Source checkout directory | Read | Required to validate Architect source files
Build staging directory | Write | Required to emit the JSON validation report
Azure Artifacts npm feed | Read | Required to install the CLI package during pipeline setup
Production Architect runtime | None | No connection to the runtime is needed or used
Production database | None | Static analysis reads text only — no database connection
File shares / UNC paths | None | Validation is scoped to the repository checkout
Internet (beyond Azure Artifacts) | None | No external calls; private feed satisfies all package needs

If the organisation uses self-hosted agents, this permission model can be enforced at the OS level (service account with minimal privileges).
Supply Chain

## Dependency and version controls

#### Zero runtime dependencies

The validation engine has no third-party runtime dependencies — only Node.js built-ins and the VS Code extension API. There is no supply-chain attack surface from npm transitive dependencies.

#### Exact version pinning

All package references use exact versions (not semver ranges). No version can be automatically promoted without a deliberate change and review. The code that was audited is the code that runs.

#### Private Azure Artifacts feed

Packages are published to an Azure Artifacts feed scoped to the organisation. No package is downloaded from the public npm registry at pipeline runtime — only from the organisation's own feed.

#### Internal source — no external contributors

The codebase is maintained internally. There are no open-source contributors, no pull requests from unknown parties, and no automatic dependency update bots.

The zero-runtime-deps point is often the most reassuring to a security audience — it removes an entire category of risk.
Explicit Constraints

## What the tooling is architecturally incapable of

These are not policy constraints — they are architectural ones. The code does not contain these capabilities.

#### Cannot connect to any database

The engine reads plain text files. It has no database driver, no connection string, and no mechanism to establish a database session.

#### Cannot execute Architect code

The engine tokenises and analyses text. It has no Architect interpreter or runtime — it cannot invoke any Architect program logic.

#### Cannot modify source files

Output is a read-only JSON report. IDE quick fixes write changes only when the developer explicitly applies them — there is no background file modification.

#### Cannot make outbound network calls

The tooling contains no HTTP client calls, no telemetry endpoints, and no update-check mechanism. All logic is local.

This slide directly addresses fear of "what if it does something unexpected". The constraints are not promises — they are verifiable in the source code.
Summary

## Security posture at a glance

Concern | Mitigation
--- | ---
Unauthorised extension installs | Private VSIX only; Marketplace allowlist via Intune/Azure AD
Extension accessing sensitive files | Extension reads only the open workspace; VS Code Restricted Mode enforceable via policy
Pipeline touching production systems | Agent runs with read-only access to source checkout; no network route to production
Supply chain / transitive dependencies | Zero runtime dependencies; private feed only; exact version pinning
Unreviewed code entering the environment | Internal source; every release auditable before VSIX distribution
Covert outbound communication | No HTTP client, no telemetry, no update mechanism — verifiable in source

Leave this up during questions. This is the slide to screenshot for a risk register entry.