Threat Tribunal

How Data and Access Move Through the System

A useful cloud-security diagram must show more than service icons. It should show which identity connects, where data moves, what each component can do and where untrusted input enters a more trusted part of the system.

Security checkpoints

Reviewed means the checkpoint is included in this demonstration review. Target marks the expected architecture; planned marks the release roadmap.

Checkpoint Security check Review posture
CP1 The public entry point requires sign-in. Reviewed
CP2 Application identities have only the access they need. Reviewed
CP3 Microsoft Entra ID controls data access and local access keys are disabled. Target
CP4 Passwords and keys stay in Azure Key Vault with limited access. Reviewed
CP5 Uploaded documents remain untrusted at intake and at the AI call. Reviewed
CP6 The release admits only an approved container image digest. Planned
CP7 The release pipeline uses a short-lived Microsoft Entra ID identity. Planned
CP8 Administration and data-access logs remain separate. Reviewed
CP9 Alert rules route to an assigned, tested response path. Reviewed
Boundary A private network boundary surrounds the data and AI services. Target

Click or tap a zone or checkpoint on the diagram to jump to the related illustrative security examples.

Trust-boundary diagram of a fictional Azure platform. Checkpoints CP1 through CP9 show where the review checks public entry, application identities, stored credentials, untrusted AI input, approved container images, security logs and alert routing. A target private network boundary surrounds the data and AI services.
Security checkpoints the review verifies, overlaid on the illustrative platform. [target] marks expected controls; [planned] marks the designed release roadmap. See also the full reference architecture on the report overview.
Architecture question Security purpose
Access and data boundaries
Which identity performs each service-to-service call? Checks that each identity has only the access it needs and that enforced policy, not an application assumption, decides permission.
Where does client information cross a service boundary? Identifies requirements for encryption, permission checks, audit records and limits on collected or retained data.
Application and deployment controls
Which component can transform or act on model output? Locates the fixed code check around AI output that can vary.
Which controls exist only in deployment configuration? Highlights differences that can develop between cloud setup files and the live environment.

Fictional Security Examples

Illustrative Architecture and Trust-Boundary Examples

Illustrative only - not an engagement finding

A Public API Can Accept Sensitive Requests Without Checking Access

Critical See where this finding applies on the diagrams: application zone · upload and intake step · CP1 public ingress
Business summary
A public Azure API must establish a trusted identity boundary before sensitive requests reach application code. It must validate the caller's Microsoft Entra ID token, admit only approved application roles and keep service identities separate.
Assessment profile
Ease of attack
A reachable API accepts the requestA caller reaches a Container Apps API without valid Microsoft Entra ID sign-in or an approved application role.
Impact
Protected services or privileged work are exposed
  • A caller could reach APIs and services intended only for trusted users or workloads.
  • A caller could trigger work intended for an approved user or service.
Detection difficulty
Exercise each entry pathTest signed-out, wrong-tenant, wrong-issuer, wrong-audience and wrong-role requests through the public API.
Pattern
Cloud admission before application authorizationAzure ingress and identity controls decide who may reach sensitive operations; application code separately decides which customer records and actions that caller may use.
Expected fix Verification
  1. Expected fix Require identity at public entry Container Apps ingress and Microsoft Entra ID: Require authentication before the API accepts a sensitive request.
    Verification Reject unauthorized callers Signed-out requests return 401 before application code begins sensitive work.
  2. Expected fix Validate every token boundary Microsoft Entra ID token validation: Accept only the approved tenant, issuer and API audience.
    Verification Reject tokens for another boundary Wrong-tenant, wrong-issuer and wrong-audience tokens are rejected before the API operation.
  3. Expected fix Restrict sensitive operations to approved roles Microsoft Entra ID application roles and FastAPI route policy: Map each sensitive operation to the roles allowed to reach it.
    Verification Deny the wrong application role A validly signed-in caller without the required application role receives 403, while the approved role still works.
  4. Expected fix Keep transport and ingress restrictions explicit Container Apps ingress and network configuration: Require HTTPS and expose only the intended public entry point.
    Verification Block unintended entry paths Plain HTTP, internal-only routes and unapproved ingress paths cannot reach the sensitive API.
  5. Expected fix Separate service identities Container Apps workloads, Microsoft Entra ID, Blob Storage and Cosmos DB: Give each workload only the managed-identity roles it requires.
    Verification Enforce the role boundary A service call without the required role fails, while approved service operations still complete.

Related illustrative findings: public discovery surface; customer and record authorization in the Application review.

Illustrative only - not an engagement finding

A Background Worker Can Send Privileged Requests to an Untrusted Address

High See where this finding applies on the diagrams: AI services zone · AI analysis and service-response checks · CP5 AI-call boundary
Business summary
A background worker can become a path to internal services or outside systems if it accepts a destination from an upstream response and attaches its own identity when it connects.
Assessment profile
Ease of attack
A returned address controls the next requestAn attacker influences a destination, redirect, port or DNS result that the worker follows.
Impact
The worker's authority reaches the wrong place
  • A destination could receive a privileged request or token.
  • The worker could reach an internal, cloud-metadata or otherwise unintended service.
Detection difficulty
Follow the destination through the workerTrace the original value, redirects, DNS resolution, token audience and egress decision before connection.
Pattern
The worker chooses approved destinationsA response may supply data, but server-owned rules decide where the worker may connect and when its identity is used.
Expected fix Verification
  1. Expected fix Allow only approved destinations Background-worker destination validation: Keep scheme, host and port in a server-controlled allowlist.
    Verification Reject an unapproved address An unknown host, scheme or port fails before any connection.
  2. Expected fix Block internal and metadata addresses Worker DNS and address validation: Resolve destinations before connecting and reject private, loopback, link-local and cloud-metadata addresses.
    Verification Stop internal-address attempts Each blocked address fails before a credential is attached.
  3. Expected fix Recheck redirects and DNS changes Worker HTTP client: Disable redirects or validate every redirected destination and resolved address again.
    Verification Reject a changed route A redirect or changed DNS result cannot move the request to an unapproved address.
  4. Expected fix Bind identity tokens to expected audiences Container Apps managed identity and Microsoft Entra ID: Request a token only for a fixed, expected audience.
    Verification Deny an unexpected audience A token request for any other audience fails.
  5. Expected fix Constrain outbound work Background-worker Container Apps environment: Restrict egress and enforce connection-time, response-size and retry limits.
    Verification Block excess or unapproved egress Network controls stop a missed destination, while an approved destination completes within its limits.

Related illustrative findings: identity boundary; public network paths.

Illustrative only - not an engagement finding

Public API Documentation Reveals Unnecessary Operations

Medium See where this finding applies on the diagrams: application zone · CP1 public ingress
Business summary
Documentation helps approved teams use an API. The same public documentation can give an attacker a map of administrative, diagnostic and internal operations that no anonymous caller should discover.
Assessment profile
Ease of attack
Public discovery routes can reveal the mapDocumentation, schemas or discovery routes are reachable on the public Container Apps address.
Impact
Sensitive operations become easier to find
  • An attacker learns available operations and parameters.
  • Internal routes, hostnames or provider behaviour can reveal how to target the service.
Detection difficulty
Check the public surface directlyTest documentation, schema, discovery and error routes as signed-out and differently authorized callers.
Pattern
Production exposes only the intended APIDisabled development routes stay unreachable; required documentation follows the same sign-in and role rules as the API.
Expected fix Verification
  1. Expected fix Disable unnecessary discovery routes Container Apps API production configuration: Remove public documentation, schema and discovery routes that are not needed.
    Verification Return no route A signed-out request to a disabled route returns 404.
  2. Expected fix Protect required documentation Container Apps API and Microsoft Entra ID: Require the same sign-in and role checks as the underlying API.
    Verification Reject an unauthorized reader Signed-out or wrong-role access returns 401 or 403.
  3. Expected fix Show each role only its permitted operations API documentation and schema generation: Expose only operations and schemas that the signed-in role may use.
    Verification Limit the visible contract An approved role sees only its permitted operations and schemas.
  4. Expected fix Remove implementation detail from responses API error handling: Omit internal hostnames, stack traces, provider errors and implementation-only routes.
    Verification Return a safe public error Public failures contain no internal hostname, stack trace or raw provider detail.
  5. Expected fix Gate the production surface Azure DevOps [planned] release gate: Fail the production gate when a disabled development route becomes reachable.
    Verification Catch a re-enabled route The release gate fails when a disabled route responds.

Related illustrative findings: identity boundary; privileged API operations in the companion review.