The visual field guide / eleven ideas worth seeing

See how
the pieces fit.

The route a request takes. The permission a user has. The evidence that becomes an alert. Clear diagrams for the questions behind the product names.

Look inside the idea

One request. Two connected legs.

Reverse proxy / follow the request, then trace the response back.

One request. Two connected legs.Reverse proxy / follow the request, then trace the response back. An intermediary is a place to apply controls. It is not a guarantee.DASH-SQUARED / THE VISUAL FIELD GUIDEOne request. Two connected legs.Reverse proxy / follow the request, then trace the response back.BrowserReverse proxyApplication1Request2ResponseMay cache, balance or inspectThe proxy is an intermediary.It receives the browser’s request andforwards it to the application.The controls are a separate question.An arrow through a proxy does not provethat any particular protection is enabled.An intermediary is a place to apply controls. It is not a guarantee.Illustrative model · Read the explanation, limits and sources alongside it.
The browser sends a request to a reverse proxy, which forwards it to an application. The response returns through the proxy. Optional caching, balancing and inspection are shown outside the main path. Open full graphic ↗

Follow the idea

  1. A browser asks the proxy for the portal.
  2. The proxy forwards this request to the application.
  3. The application replies through the proxy to the browser.

Keep the limit visible

Simplified un-cached request. Network layout and TLS termination vary; applications still need their own security controls.

Where does the reply travel?

In this example it returns through the proxy. A cache could serve some requests without a new origin fetch; that is a different path.

A common assumption

“A reverse proxy means the application behind it is secure.”

The proxy is a place to apply configured controls. It does not fix every weakness in the application.

Source for this graphic: www.cloudflare.com ↗ · Checked November 7, 2026 · Illustrative example.

Read the companion explanation ↗

Look inside the idea

Signed in is only the first check.

Identity / a successful sign-in does not grant every permission.

Signed in is only the first check.Identity / a successful sign-in does not grant every permission. A denied request can mean the access policy is working correctly.DASH-SQUARED / THE VISUAL FIELD GUIDESigned in is only the first check.Identity / a successful sign-in does not grant every permission.One accountIdentity verifiedDocumentsREAD ALLOWEDPayrollACCESS DENIEDAUTHENTICATIONAUTHORIZATIONIllustrative role: a team membercan read Documents, not Payroll.Same identity.Different permissions.A denied request can mean the access policy is working correctly.Illustrative model · Read the explanation, limits and sources alongside it.
A single signed-in account requests Documents and Payroll. Read access is allowed for Documents and denied for Payroll because authorization evaluates different permissions. Open full graphic ↗

Follow the idea

  1. Authentication verifies evidence for this account’s identity.
  2. Authorization allows this account to read Documents.
  3. A different permission decision denies access to Payroll.

Keep the limit visible

Conceptual distinction, not a literal Entra processing order. Actual access can also depend on application policy, device and context.

Can the signed-in user open Payroll?

No, not under this illustrative policy. A valid sign-in is compatible with a denied request.

A common assumption

“Once someone signs in, they should be able to open everything.”

A sign-in and permission to perform a particular action answer different questions.

Source for this graphic: learn.microsoft.com ↗ · Checked November 7, 2026 · Illustrative example.

Read the companion explanation ↗

Look inside the idea

The tunnel has an endpoint.

VPN / one protected leg does not describe the whole journey.

The tunnel has an endpoint.VPN / one protected leg does not describe the whole journey. Ask what enters the tunnel, where it ends and what protects the next leg.DASH-SQUARED / THE VISUAL FIELD GUIDEThe tunnel has an endpoint.VPN / one protected leg does not describe the whole journey.Work deviceVPN gatewayPrivate appVPN ENCRYPTED LEGTunnel endsat the gateway.Inside the tunnelWhich routes enter it? Full-tunnel andsplit-tunnel configurations differ.After the endpointApp permissions still apply. HTTPS/TLSmay protect the next connection.Ask what enters the tunnel, where it ends and what protects the next leg.Illustrative model · Read the explanation, limits and sources alongside it.
An encrypted VPN connection covers the leg from the work device to the VPN gateway. A visible endpoint boundary separates it from the onward application connection, which can have independent TLS and access checks. Open full graphic ↗

Follow the idea

  1. The device establishes a VPN connection to the gateway.
  2. Only traffic routed into that tunnel uses this protected leg.
  3. The VPN leg ends at the gateway; the next connection needs its own protections.

Keep the limit visible

Illustrative remote-access VPN. A VPN does not repair a compromised endpoint or automatically make a user anonymous.

Where does this VPN’s encrypted leg end?

At the VPN gateway shown here. HTTPS/TLS and the application’s permission checks are separate protections.

A common assumption

“Connected to a VPN means every part of the journey is protected.”

Identify the endpoint, which routes enter the tunnel and the controls on the next leg.

Source for this graphic: www.cloudflare.com ↗ · Checked November 7, 2026 · Illustrative example.

Read the companion explanation ↗

Look inside the idea

A record is not an alert.

Detection / separate the evidence, the condition and the follow-up.

A record is not an alert.Detection / separate the evidence, the condition and the follow-up. No alert is not proof that nothing happened.DASH-SQUARED / THE VISUAL FIELD GUIDEA record is not an alert.Detection / separate the evidence, the condition and the follow-up.1 / COLLECTED RECORDS09:00 Sign-in failed09:01 Sign-in failed09:02 Sign-in failed2 / EXAMPLE RULE3 failures insidea 5-minute window3 / ALERTNeeds reviewNot a verdictA record describes an event.A rule or detection interprets a pattern.The threshold here is fictional.An alert starts the investigation.Missing data, rule coverage and routingcan all explain why an alert is absent.No alert is not proof that nothing happened.Illustrative model · Read the explanation, limits and sources alongside it.
Three fictional failed-sign-in records feed an example rule: three failures within five minutes. A matching rule creates an alert for review, not a confirmed finding. Missing collection or coverage can hide events. Open full graphic ↗

Follow the idea

  1. The system collects three fictional failed-sign-in records.
  2. An example condition looks for three failures within five minutes.
  3. A matching condition produces an alert for investigation.

Keep the limit visible

Synthetic threshold, not security advice. Detection and notification behavior depend on rule type, deployment and configuration.

Does this alert prove an attack happened?

No. A user typing an old password might match this fictional rule. An event that was never collected could be missed entirely.

A common assumption

“No alert means nothing happened.”

Collection, detection coverage and notification routing can each have gaps.

Source for this graphic: www.elastic.co ↗ · Checked November 7, 2026 · Illustrative example.

Read the companion explanation ↗

Look inside the idea

Three lenses. One slow request.

Observability / connect records, measurements and a request’s path.

Three lenses. One slow request.Observability / connect records, measurements and a request’s path. Searchable data helps the investigation. Context makes it useful.DASH-SQUARED / THE VISUAL FIELD GUIDEThree lenses. One slow request.Observability / connect records, measurements and a request’s path.A USER REPORTS: “THE PORTAL IS SLOW.”LOGSWhat happened?“Database timeout”METRICSHow much?Latency rises at noonTRACESWhere was the time?Database call: 800 msOne investigation. Different kinds of evidence.Searchable data helps the investigation. Context makes it useful.Illustrative model · Read the explanation, limits and sources alongside it.
Logs supply event detail, metrics show measurements over time, and traces show where time was spent along an instrumented request. A fictional slow-portal example brings the three evidence types together. Open full graphic ↗

Follow the idea

  1. A log records an event such as a database timeout.
  2. A metric shows a measurement changing over time.
  3. A trace can show time spent in the instrumented parts of one request.

Keep the limit visible

Illustrative observability use case, not a screenshot or an exhaustive description of Elastic. Correlation requires suitable collection, timing, instrumentation and context.

Which evidence would help locate the slow call?

A suitable trace can locate time spent along that request. Logs and metrics provide different context; none guarantees complete visibility.

A common assumption

“One dashboard sees everything.”

Only collected, retained and properly correlated data can contribute to the picture.

Source for this graphic: www.elastic.co ↗ · Checked November 7, 2026 · Illustrative example.

Read the companion explanation ↗

Look inside the idea

Sharing is an access decision.

Password management / the vault and the target service are different systems.

Sharing is an access decision.Password management / the vault and the target service are different systems. Manage shared access and the lifecycle of the underlying credentials.DASH-SQUARED / THE VISUAL FIELD GUIDESharing is an access decision.Password management / the vault and the target service are different systems.Team collectionShared itemsControlled accessApproved userDeparting userCAN USE ITEMSREVOKE ACCESSAccess revoked ≠ external password changed.Rotate affected credentials where exposure or policy requires it.Manage shared access and the lifecycle of the underlying credentials.Illustrative model · Read the explanation, limits and sources alongside it.
An organization-owned collection gives approved people access to shared items. Revoking a departing user’s vault access is separate from changing the password at an external service. Open full graphic ↗

Follow the idea

  1. An organization shares selected items through a collection.
  2. Approved users receive the relevant collection permissions.
  3. Offboarding removes access; affected external credentials may also need rotation.

Keep the limit visible

Conceptual example. Account recovery, permissions, exports and revocation behavior vary; review the current organization setup and credential-rotation requirements.

Does removing vault access change an external password?

Not by itself. Access to the vault and the password at the external service are separate. Review rotation when exposure or policy requires it.

A common assumption

“Removing a user from the vault makes every copied password unusable.”

Review the underlying service credentials and sessions as part of offboarding.

Source for this graphic: bitwarden.com ↗ · Checked November 7, 2026 · Illustrative example.

Read the companion explanation ↗

Look inside the idea

From device activity to a decision.

Endpoint security / visibility, detection and response are different jobs.

From device activity to a decision.Endpoint security / visibility, detection and response are different jobs. A detected signal needs context. A response needs a policy and an owner.DASH-SQUARED / THE VISUAL FIELD GUIDEFrom device activity to a decision.Endpoint security / visibility, detection and response are different jobs.Managed endpointProcess startsDevice activity createssignals for analysis.Signals + contextCollect activityEvaluate detectionsInvestigationInspect evidenceDecide actionExample response: isolate a deviceOnly where supported and authorized.ONE ENDPOINT-SECURITY EXAMPLEA detected signal needs context. A response needs a policy and an owner.Illustrative model · Read the explanation, limits and sources alongside it.
Managed-device activity supplies telemetry that detections can evaluate. An investigation examines evidence and selects a response. Device isolation is shown as one possible supported, authorized response rather than an automatic certainty. Open full graphic ↗

Follow the idea

  1. A managed endpoint produces activity signals.
  2. Detections evaluate collected signals in context.
  3. Investigation and policy determine the supported response.

Keep the limit visible

One endpoint-detection-and-response concept, not the whole CrowdStrike platform. Available controls, automation and coverage depend on licensed products and deployment.

Is detecting activity the same as preventing it?

No. Collection, detection and response are distinct. Some actions can be automated; availability and behavior depend on deployment and policy.

A common assumption

“An endpoint agent guarantees every threat will be stopped.”

Check actual device coverage, telemetry, enabled controls and who owns response.

Source for this graphic: www.crowdstrike.com ↗ · Checked November 7, 2026 · Illustrative example.

Read the companion explanation ↗

Look inside the idea

Reach the app you are allowed to use.

Private access / a permitted connection is not a blanket network pass.

Reach the app you are allowed to use.Private access / a permitted connection is not a blanket network pass. Ask which application is permitted, for whom and under what conditions.DASH-SQUARED / THE VISUAL FIELD GUIDEReach the app you are allowed to use.Private access / a permitted connection is not a blanket network pass.User + deviceAccess policyApproved appCONNECTAnother appNOT PERMITTEDA REQUEST FOR ONE APPLICATIONIdentity, device and context can informa policy decision for a specific app.Ask which application is permitted, for whom and under what conditions.Illustrative model · Read the explanation, limits and sources alongside it.
A user and device request a specific private application. Policy permits the approved application without granting access to another application. Identity, device and context can inform the decision. Open full graphic ↗

Follow the idea

  1. A user and device request a particular application.
  2. Configured access policy evaluates the request and relevant context.
  3. The allowed connection does not grant permission to a different application.

Keep the limit visible

Conceptual ZTNA example for ZPA, not a literal connection sequence or network architecture. Real deployment includes additional services and connectors; exact policy must be checked.

Does reaching this app authorize another app?

No. The pictured grant is for the approved app, not a blanket network pass. App-level permissions can still restrict what the user does inside it.

A common assumption

“A private access connection is permission to use any resource behind it.”

Check the named application, eligible users and conditions, then the permissions enforced inside the app.

Source for this graphic: www.zscaler.com ↗ · Checked November 7, 2026 · Illustrative example.

Read the companion explanation ↗

Look inside the idea

Sent. Accepted. Seen? Different evidence.

Email delivery / follow the handoff without overstating the outcome.

Sent. Accepted. Seen? Different evidence.Email delivery / follow the handoff without overstating the outcome. Authenticate the sender. Trace the handoff. Verify placement separately.DASH-SQUARED / THE VISUAL FIELD GUIDESent. Accepted. Seen? Different evidence.Email delivery / follow the handoff without overstating the outcome.Mailbox / appSending serviceAttempt recordedOutcome eventsRecipient serverInboxOther folderAuthentication is about sending identity.SPF / DKIM / DMARC help establish identity.They do not guarantee placement or a human read.Acceptance ≠ inboxFolder examples onlyOther outcomes are possible.Authenticate the sender. Trace the handoff. Verify placement separately.Illustrative model · Read the explanation, limits and sources alongside it.
A sender or application uses a sending service, which attempts delivery to a receiving server. Receiving-server acceptance is a different fact from inbox placement, and neither proves a person read the message. Open full graphic ↗

Follow the idea

  1. The sender or application submits a message to its sending service.
  2. The receiving server may accept, defer or reject the attempt.
  3. Placement and a human reading the message are separate outcomes.

Keep the limit visible

Simplified successful handoff, not every delivery state. Bounces, deferrals, suppressions and spam decisions can interrupt or change the path. Authentication is not a placement guarantee.

Does receiving-server acceptance prove a human saw it?

No. A receiving-server acceptance event does not establish inbox placement or a human read.

A common assumption

“An authenticated, delivered message must be in the inbox.”

Keep identity checks, receiving-server acceptance, placement and reading evidence separate.

Source for this graphic: www.twilio.com ↗ support.google.com ↗ · Checked November 7, 2026 · Illustrative example.

Read the companion explanation ↗

Look inside the idea

A good draft is not permission to send.

AI and automation / separate a proposed result from an authorized action.

A good draft is not permission to send.AI and automation / separate a proposed result from an authorized action. Choose where AI helps, where checks run and who may authorize the action.DASH-SQUARED / THE VISUAL FIELD GUIDEA good draft is not permission to send.AI and automation / separate a proposed result from an authorized action.MODELProposes a draftMay be wrongREVIEWCheck the factsApprove the actionSending toolACTION BOUNDARYThe model is one component.An assistant is the application people use.A workflow can run without a model.An agent can choose steps or tools.Its actual permissions must still be bounded.Human review is the policy in this example.Choose where AI helps, where checks run and who may authorize the action.Illustrative model · Read the explanation, limits and sources alongside it.
In a synthetic follow-up workflow a model proposes a draft, review checks it, and only an approved action crosses a marked boundary to a sending tool. The model, assistant application and workflow are different roles. Open full graphic ↗

Follow the idea

  1. A model proposes a result inside an application.
  2. The example workflow validates the draft and obtains human approval.
  3. Only the authorized action crosses to the sending tool.

Keep the limit visible

This is one approval policy, not a definition of every agent. Models can produce errors; tool permissions, allowed data and failure handling remain application responsibilities.

May the model draft send itself?

Not in this example. The workflow requires review and approval before the tool may send. Other systems need their own explicit policy.

A common assumption

“If an AI answer is convincing, it is safe to let it act.”

Evaluate the output and separately constrain the system’s authority to take actions.

Source for this graphic: developers.openai.com ↗ docs.n8n.io ↗ · Checked November 7, 2026 · Illustrative example.

Read the companion explanation ↗

Look inside the idea

Connected does not mean synchronized.

Business integration / decide who owns the record and how failures recover.

Connected does not mean synchronized.Business integration / decide who owns the record and how failures recover. Name the source of truth, the record ID and the exception owner.DASH-SQUARED / THE VISUAL FIELD GUIDEConnected does not mean synchronized.Business integration / decide who owns the record and how failures recover.Source recordStable source IDIntegrationValidate + map fieldsCheck repeated eventsTarget recordAPI / eventException ownerReview + reconcileA retry is not automatically safe.Repeated events should not create duplicate actions.Use stable IDs, suitable retries and reconciliation.Name the source of truth, the record ID and the exception owner.Illustrative model · Read the explanation, limits and sources alongside it.
A source record identified by a stable ID feeds an integration that validates fields, maps data and handles repeated events before updating a target record. Failed work goes to an exception owner for reconciliation. Open full graphic ↗

Follow the idea

  1. Identify the source record and the fields it owns.
  2. Validate, map and handle repeats before changing the target.
  3. Send failed or conflicting work to an owner for reconciliation.

Keep the limit visible

Conceptual design, not a universal exactly-once guarantee. Interfaces, transaction semantics, ordering and retry behavior differ. Each target operation needs an explicit recovery design.

What if the same event arrives twice?

Use stable event/record identity and an operation-specific strategy so a repeat does not create an unintended duplicate. Some interfaces require reconciliation rather than a blind retry.

A common assumption

“Connecting two systems means their records will stay consistent.”

Ownership, mappings, duplicate handling and recovery need a deliberate design.

Source for this graphic: learn.microsoft.com ↗ www.twilio.com ↗ · Checked November 7, 2026 · Illustrative example.

Read the companion explanation ↗