Security & governance model

Zero-Trust is enforced.
Not assumed.

Verify who and what is requesting access, authorize only the required resources, and preserve evidence across an agent’s actions and memory.

Reference model B5 Edge · AWS · Tenant memory

Zero-Trust at every boundary.

No implicit trust comes from network location or device ownership. Authenticate and authorize both the subject and device before establishing a resource session.

Verify explicitly

Validate caller identity at the API and device identity through mTLS; evaluate device state and resource permissions before granting access.

Least-privilege access

Limit service roles, connector tools and tenant data to the required scope, with per-client consent and exact-action approval for writes.

Assume breach

Contain misuse with tenant isolation and bounded tool authority; review immutable decision evidence and rehearse the kill switch and rollback.

Standards reference: NIST SP 800-207 — Zero Trust Architecture

01 / Control architecture

Every boundary has a purpose.

Select a domain to explore its controls and where they are enforced.

Identity, action and evidence
across three architectural zones.

01 / At the edge

Dealer edge

Device & connection boundary

02 / In the application

AWS application

Identity & action boundary

03 / In memory

Governed memory

Tenant & evidence boundary

Explore controls by boundary: dealer edge, AWS application and governed memory.

Control details

01 / Dealer edge

Edge & device

Keep the connector boundary small: a hardened host, outbound-established sessions, and tools that remain local to the device.

Controls in this domain

Harden the connector host

Use a managed host with a hardened operating system to reduce the connector’s exposed services and local privileges. Verify configuration and patch state when evaluating device access, rather than treating host ownership as proof of trust.

Outbound-only connectivity

Have the host initiate authenticated sessions without exposing public inbound connector ports. Restrict outbound destinations to approved services and authorize resource access within each session; connection direction alone does not grant permission.

Loopback-only tool access

Bind local tool endpoints to the host’s loopback interface to limit direct network exposure. Check the calling process and its authorized tool scope before execution, because local reachability is not an authorization decision.

Related checkpoints

mTLS on edge

What remains

A compromised endpoint can still issue valid requests. Host controls reduce exposure, not every consequence of compromise.

02 / Enforcement

Five checkpoints.
One consistent boundary.

Where identity, tenant scope and tool permissions become explicit policy decisions.

03 / Residual risk

Controls reduce risk.
They don’t remove it.

01 / Judgment

An agent can be wrong within its permissions.

Authorized does not mean correct. Approval gates and review still matter.

02 / Endpoint trust

A compromised endpoint can still issue valid requests.

Valid identity alone does not establish the intent of a request.

03 / Tenant isolation

Tenant isolation must be enforced and tested in the database.

It cannot be inferred from application code.

Rate limits, approval gates, and anomaly review reduce impact rather than eliminate it.

Zero-Trust is enforced.Not assumed.