Architecture and Trust Boundaries

Illustrative Findings Boundary

The severity-labelled scenarios below are newly authored fictional examples informed by the control domains assessed in this work. They do not reproduce or summarize any engagement finding, do not describe the reviewed environment, and do not indicate that any weakness was observed, confirmed, remediated or remains outstanding. Severity labels apply only to these examples and illustrate prioritization methodology.

Each example combines a plain-English business summary, a technical condition, potential impact, the evidence an assessment would seek, the expected control and a measurable way to check the fix.

A useful cloud-security diagram must show more than service icons. It should expose identity, data direction, privilege and the point at which untrusted input crosses into a more trusted processing context.

Trust-boundary diagram of the illustrative platform: amber checkpoint markers CP1 through CP9 cover public ingress, managed-identity edges, Entra-only data planes, the secrets boundary, the untrusted-content boundary at the AI call, the planned supply-chain gate and workload identity federation, telemetry separation and alert routing, with a target private-connectivity perimeter around the data and AI zones. — Security checkpoints the review verifies, overlaid on the illustrative platform. [target] marks expected controls; [planned] marks the designed delivery roadmap. See also the full reference architecture on the report overview.

Architecture question	Security purpose
Which identity performs each service-to-service call?	Tests least privilege and removes authorization decisions from application convention.
Where does client information cross a service boundary?	Identifies encryption, authorization, audit and data-minimization requirements.
Which component can transform or act on model output?	Locates the deterministic validation boundary around probabilistic behavior.
Which controls exist only in deployment configuration?	Highlights drift risk between infrastructure definitions and the live environment.

Fictional Security Examples

Illustrative Architecture and Trust-Boundary Examples

Illustrative only - not an engagement finding

Sensitive Operations Lack a Default-Deny Identity Boundary

Critical See where this finding applies on the diagrams: application zone · upload and intake step · CP1 public ingress

Ease of Attack: Low effort if internet-facing
Impact: Protected records and privileged operations
Detection Difficulty: Visible in unauthenticated endpoint probing
Pattern: Example identity and authorization pattern

Business Summary: A public service that accepts sensitive requests without sign-in or per-customer authorization can turn an ordinary endpoint into direct access to protected records and operations.
Possible Weakness: An internet-facing API permits sensitive operations without requiring an authenticated identity and without rechecking object or tenant authorization downstream.
Potential Impact: An external caller could read or change sensitive information, trigger privileged processing or cross a customer boundary.
What an Assessment Verifies: Inspect Container Apps ingress and Entra ID identity settings, trace downstream authorization decisions and run safe tests that confirm access is denied without retrieving real data.
Expected Fix: Enforce identity at the Container Apps ingress and default-deny authorization at the API, object and tenant boundaries.
How to Check the Fix: Signed-out requests and requests using the wrong tenant, role or object identity must fail with 401 or 403 without revealing whether a protected record exists. Repeat the negative tests after every deployment.

Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how a real report connects one conclusion to complementary sources. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.

Example read-only Azure configuration record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
```
az resource show --ids "<illustrative-resource-id>" \
  --query "properties.exampleControl"

Illustrative output: {"exampleControl":"enabled"}
```
Example source-code authorization reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
```
if not policy.can_access(actor, record):
    raise Forbidden()
```
Example reproducible denied-access test output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
```
security-check --target "<illustrative-target>" --format json
Illustrative output: {"result":"control verified"}
```

Illustrative only - not an engagement finding

Privileged Service Follows an Untrusted Callback Destination

High See where this finding applies on the diagrams: AI services zone · AI analysis callback step · CP5 AI-call boundary

Ease of Attack: Requires control of a returned destination
Impact: Credential disclosure or unintended requests
Detection Difficulty: Requires tracing callback handling through service code
Pattern: Example destination-validation pattern

Business Summary: A trusted workload can hand its authority to an attacker-controlled destination when it accepts dynamic callback addresses and attaches privileged credentials to the resulting request.
Possible Weakness: A backend service accepts a callback or status address from an upstream response and sends a privileged credential to that destination.
Potential Impact: A manipulated destination could receive credentials or cause the workload to issue unintended outbound requests.
What an Assessment Verifies: Trace where each callback destination originates, how redirects and DNS lookups are handled, when credentials are attached and the outbound network policy of the async worker's Container Apps environment.
Expected Fix: Use fixed or allow-listed destinations, never attach managed-identity credentials to dynamic URLs and restrict the worker's outbound connections.
How to Check the Fix: Safe tests using an unapproved host, redirect, private address, unexpected port and changed DNS result must all fail before a credential is attached or an outbound connection is made.

Cross-Reference Evidence (Illustrative). This is cross-reference evidence showing how the private reports connect this example’s verification to complementary sources. In a real engagement each item below is a live pointer: a file-and-line link into the source repository, a reproducible read-only query against the deployed Azure environment, or replayable tool output. Here they lead to newly authored public demonstrations.

Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
```
az resource show --ids "<illustrative-resource-id>" \
  --query "properties.exampleControl"

Illustrative output: {"exampleControl":"enabled"}
```
Example source-code evidence reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
```
if not policy.can_access(actor, record):
    raise Forbidden()
```
Example reproducible tool output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
```
security-check --target "<illustrative-target>" --format json
Illustrative output: {"result":"control verified"}
```

Illustrative only - not an engagement finding

Public Discovery Surface Reveals Unnecessary Operations

Medium See where this finding applies on the diagrams: application zone · CP1 public ingress

Ease of Attack: Trivial when publicly reachable
Impact: Faster discovery of sensitive operations
Detection Difficulty: Visible in anonymous discovery checks
Pattern: Example production-surface pattern

Business Summary: Production documentation helps legitimate teams use a service, but exposing internal and administrative operations also reduces the discovery work required by an attacker.
Possible Weakness: Production documentation or an API schema is available without sign-in and lists administrative, diagnostic or internal operations.
Potential Impact: The exposed surface gives an attacker a clearer map of available operations, parameters and implementation behaviour.
What an Assessment Verifies: Check signed-out access to documentation, schemas and discovery endpoints on the public Container Apps ingress and compare the result with the intended production audience.
Expected Fix: Disable unnecessary discovery surfaces in production or place them behind the same Entra ID identity and authorization boundary as the API.
How to Check the Fix: Signed-out requests to documentation, schema and discovery routes must return 401, 403 or 404. Approved users should see only the operations their role is permitted to invoke.

Example read-only Azure evidence record
This is cross-reference evidence. A real assessment records the dated read-only query, the relevant property and the evidence limit without exposing credentials or customer data.
```
az resource show --ids "<illustrative-resource-id>" \
  --query "properties.exampleControl"

Illustrative output: {"exampleControl":"enabled"}
```
Example source-code evidence reference
This is cross-reference evidence. A real assessment links a conclusion to the reviewed commit and exact lines so another technical reader can inspect the same enforcement point.
```
if not policy.can_access(actor, record):
    raise Forbidden()
```
Example reproducible tool output
This is cross-reference evidence. A real report retains the command, tool version, safe input boundary and output needed to reproduce the conclusion.
```
security-check --target "<illustrative-target>" --format json
Illustrative output: {"result":"control verified"}
```

Azure Review · Control Domain 1 of 5 · Public Edition

Part of the two-report public security-review portfolio.

Report overview