PROTECTEDCODE runs approved coding models inside the Government of Canada environment your organization already operates — and makes your department's engineering standards active while the code is being written. Visual Studio and VS Code connect directly to a private endpoint; there is no proprietary extension to package, approve and deploy to managed workstations.
Your developers keep using the IDE they already have. The AI runs inside your approved environment instead of sending Protected code to a public coding service — and writes toward your architecture standards rather than against them.
The PROTECTEDCODE platform does not transmit source code, prompts, embeddings or retrieved application context to public AI services.
“You must consider the security classification of the code.” — Treasury Board Secretariat, Guide on the use of generative AI
You do not need to be an AI specialist to understand the PROTECTEDCODE architecture. Think of it as adding capabilities to an assistant one layer at a time. The tag beside each layer says plainly where it stands today.
The large language model is the core reasoning engine. PROTECTEDCODE serves only an approved, validated model and version through the private coding endpoint. Your department controls where that model runs and which model is approved.
A coding model cannot be expected to already know your application, your architecture documents or your department's standards. Project-Isolated Code RAG gives the assistant controlled access to what is relevant to the repository it is working on — source code, approved technical documentation and internal standards — and retrieval stays scoped to the authorized project.
Model Context Protocol, or an equivalent approved interface, can give the assistant a standard way to work with internal engineering services — for example Azure DevOps, Git repositories, approved NuGet feeds, build and test services, architecture standards or vulnerability information. PROTECTEDCODE does not give the AI unrestricted access: every connection is explicitly approved, authenticated and constrained by policy.
A skill is a reusable procedure the assistant can follow instead of rediscovering the process every time. Skills can combine department standards, Engineering Profiles, approved tools and validation steps. Examples could include:
modernize-legacy-servicecreate-unit-testsreview-clean-architecturecheck-accessibilityevaluate-new-nuget-packageprepare-security-reviewAn agent goes beyond answering a question. It can be given a goal, decide on a sequence of steps, use approved tools, inspect the result and continue until the bounded task is complete. A PROTECTEDCODE agent operates inside a sandbox with least-privilege access, tool allowlists, project boundaries, audit records and human confirmation where required.
$ policy explain --request 7f2a identity: entra://department/user project_scope: benefits-modernization profile: clean-architecture@2.3 # bound to this repository backend: <department-approved model/version> secret_scan: PASS (pre-inference) retrieval: module not enabled in this deployment public_ai: NOT USED BY PROTECTEDCODE audit: request + decision + profile version
Most departments already have architecture standards. Most of them live in a document nobody opens, enforced — if at all — by an analyzer that rejects code after it has been written. PROTECTEDCODE binds the same standard into generation: architects publish versioned engineering profiles, each repository or solution binds a profile and version, the assistant receives that profile when it generates and reviews, and deterministic tooling then verifies the rules that can be enforced mechanically.
# .protectedcode/profile.yml — bound to this repository, versioned with it profile: clean-architecture version: 2.3 owner: enterprise-architecture architecture: forbidden: [ presentation -> infrastructure.persistence ] required: [ use-case boundary for cross-aggregate writes ] validated_by: [ roslyn-analyzers, architecture-tests ] security: packages: approved-feed-only secrets: no literals in source or prompts validated_by: [ sast, dependency-scan, secret-scan ] web: baseline: gc-web-accessibility validated_by: [ automated-a11y, human review ] exceptions: - rule: presentation -> infrastructure.persistence scope: LegacyReportsController.cs approved_by: solution-architect expires: 2027-03-31
Clean, Onion, Layered, Legacy Maintenance or your own pattern. Allowed and forbidden layer and project dependencies, declared per repository rather than imposed as one global house style.
validated_by: roslyn analyzers · architecture tests · project-reference rulesDependency injection, async, logging, exception handling, naming, API and testing conventions as your department actually writes them.
validated_by: compiler + analyzer rules · formatter · unit testsAuthentication and authorization patterns, secret handling, cryptography rules, approved NuGet feeds and dependency policy.
validated_by: sast · secret scanning · dependency/SBOM checks · CI policyWET/GCWeb implementation guidance, accessible component patterns and WCAG requirements applied to generated and reviewed UI code.
validated_by: automated a11y testing · component tests · human reviewProfile ID and version, repository binding, migration status and approved deviations — so exceptions are visible rather than silent.
validated_by: versioned policy file · code review · exception workflowA stable OpenAI/Ollama-compatible surface that abstracts the model behind it, with public model services blocked.
egress.public_model = deniedPrompt, code and context are inspected for credentials, connection strings, keys and tokens before anything reaches the model.
secret_scan = pre_inferenceA versioned profile is bound per repository or solution and supplied to the model as explicit generation and review context.
profile.scope = repositoryRoslyn, architecture-test, security, package and accessibility checks verify the rules that can be enforced mechanically.
enforcement != promptOnly approved model and version profiles are served. Versions are pinned and never change silently underneath a team.
model.version = pinnedA locally validated signed licence avoids a supplier call-home dependency in restricted or disconnected environments.
license.callhome = falseRepository-aware retrieval with per-project indexes, retrieval-time authorization and provenance. Added where large or legacy solutions require it.
index.scope = projectCentralized identity-aware profile selection, model routing, provenance and SIEM-ready audit where direct clients cannot provide sufficient control.
audit.sink = customer_siemLeast-privilege workers, tool allowlists, diff review and confirmation gates. Retrieved repository text is never privileged instruction.
retrieval.privilege = nonePrivate workload and private AI processing. Management access follows the authorized landing-zone pattern; the data plane can remain isolated.
egress: approved management path onlyStronger segmentation, private endpoints and centralized logging. Exceptions require explicit customer approval.
egress: deny by default / approved exceptionDepartmental Azure Landing Zone. Preferred where the sponsoring department already has an approved landing zone and private connectivity — the fastest likely path to a paid pilot.
status: first-customer, preferredDepartmental private cloud / on-premises / enterprise data centre, including VMware. Equivalent first-customer route where infrastructure and SA&A are already established, or dedicated isolation/GPU ownership is preferred.
status: first-customer, equivalentGC AI Platform / SSC sovereign AI infrastructure. Pursued in parallel as a shared-infrastructure channel — not a dependency for first revenue until SSC confirms third-party workload onboarding.
status: strategic channel, parallelIndependent ThinkOn PBMM deployment. Alternate sovereign Canadian hosting where neither the departmental route nor GC AI Platform is presently suitable.
status: alternate sovereign hostChat and agent workflows against your private endpoint using the IDE's own model-provider configuration. Feature-by-feature behaviour with public endpoints blocked is part of the pilot validation matrix.
endpoint: privateModel-provider extensions validated against the same private endpoint and Ollama/OpenAI-compatible protocol — no proprietary extension required.
endpoint: privateCustomer-controlled models run inside the AI data plane with no direct Internet egress.
isolation: maximumExisting Entra identity supports authentication and project authorization — no separate developer identity store.
auth: entra_awareRequest, policy and tool-action records remain in customer-controlled logging. Tamper-evident or signed capability can be deployment-specific.
sink: existing_siemThe endpoint can adopt future SSC-provided inference without replacing the engineering-governance layer above it.
route: future_profileUse private endpoints where feasible; disable public access where supported.
Self-hosted inference and, where enabled, RAG and workers operate without direct Internet egress.
Routes and firewall rules allow only reviewed, deployment-specific exceptions.
Request content is inspected for credentials and keys before it enters model context; block, redact or warn by policy.
Records go to the departmental SIEM; prompt-body logging is minimized or disabled by default.
Models, documentation and packages use a controlled import path separate from Protected traffic.
Before a model and runtime are promoted for a pilot, pass/fail thresholds are declared in advance and recorded: grounded code-comprehension accuracy, build and test pass rates on bounded generation, legacy .NET task success, seeded architecture-rule detection, interactive and completion latency, and zero-tolerance gates for cross-repository retrieval leakage, secret exfiltration and policy escapes — each measured over a stated number of adversarial attempts. Thresholds change only by an explicit versioned decision, never after seeing a result.
| THREAT | EXAMPLE | CONTROL |
|---|---|---|
| Repository prompt injection | A comment instructs the agent to ignore policy | Retrieved text is never privileged instruction |
| Guardrail bypass / architectural erosion | Generated code follows the prompt but violates the active Clean/Onion rules | Active profile bound into generation; analyzers and architecture tests reject enforceable violations |
| Policy drift / stale standards | A repository stays bound to an obsolete architecture or accessibility profile | Versioned profiles, recorded bindings, migration status and controlled upgrade decisions |
| Malicious dependency | Vendored content targets the agent | Package provenance and sandboxed execution |
| Cross-project leakage | A query retrieves another project's code | Per-project indexes and retrieval-time authorization |
| Destructive action | An agent changes or deletes unexpected files | Allowlist, diff review, confirmation and rollback |
| Model drift | An unreviewed model update changes behaviour | Pinned versions, evaluation gate and signed promotion |
PROTECTEDCODE is a product and a working design. Authorization is a departmental decision.
The hosting boundary, the controls and your risk acceptance do that.
Mechanically enforceable rules are verified by analyzers and tests, or they are not claimed.
Tooling catches part of it; human review remains in the path for the rest.
C#/.NET today. Other ecosystems clear the same benchmark and evaluation bar before we claim them.
We supply application evidence, threat model, control mappings, secure-development evidence and test results. Your organization owns risk acceptance and the authorization decision.
Developers carrying Protected code stay without an approved capability for however long the wait lasts.
Consumer tools become more reachable every quarter. The unsanctioned path does not pause while procurement does.
You learn nothing about what conformant AI-assisted development does to your codebase until you run some.
Licensing is scoped per protected environment, with developer seats separate. You pay for your own approved compute and storage through your existing cloud or hosting arrangement; PROTECTEDCODE adds no token billing on top of it. Pilot and annual figures are scoped to the deployment and the number of developers — we would rather put real numbers against a real scope than publish a tier that fits nobody.
An annual licence per protected environment covers the private endpoint, validated model and runtime profile, engineering-profile binding and validation hooks, deployment tooling and software updates.
unit: protected environmentDeveloper seats are licensed separately so cost scales with realized use, and can be converted to enterprise bands where that simplifies procurement.
unit: named developerCode RAG, centralized policy broker, audit and provenance services and sandboxed agent tooling are licensed as modules, added when requirements justify them.
unit: module, per environmentCompute, storage and GPU are yours, billed by your own provider at your own rates. No token-based billing is added by PROTECTEDCODE.
billed_by: customerLicence validation uses a cryptographically signed file checked locally. No call-home to a supplier system is required, and restricted or disconnected environments are supported by design.
license.callhome = falseA short technical discovery session with your development platform, architecture and security stakeholders: confirm which approved boundary a pilot would run in, agree what a pilot boundary looks like, and identify which repositories would benefit most from profile-bound assistance. Pilots begin on owned or Unclassified code, so quality, latency and no-egress behaviour are measured and documented before any Protected workload is involved.
randy@protectedcode.ca