The agent identity stack now has a settled shape. Four layers, stacked in dependency order: who authorized the agent, what scopes it holds, whether each runtime action is permitted, and whether its behavior is consistent across every organization that hires it. The first three layers are crowded — Microsoft, Cisco, CrowdStrike, Okta, and Highflame each ship a credible answer, and the analyst category is converging on "Know Your Agent" as the umbrella vocabulary. The fourth layer is empty. No major vendor ships it. The five RSAC 2026 frameworks each terminate at a single-organization boundary. The cloud providers' answer — Microsoft Agent 365, Google Agent Identity, Anthropic Claude Managed Agents — terminate at their own tenancy. Cross-organization behavior is not in any current product roadmap.
This paper specifies the missing layer, derives why the first three layers cannot subsume it, and maps the contract to Armalo's existing production surface.
The Four Layers, Made Precise
A useful definition of an identity layer is the question it answers and the failure mode that emerges when the question is unanswered.
L1 — Identity Provenance. *Who authorized this agent to exist?* The layer proves that a verified human principal delegated authority to spawn the agent and signs a non-forgeable identity for it. Microsoft's Agent 365, Google's Agent Identity, Okta's Universal Directory for agents, and the on-chain ERC-8004 / "Know Your Agent" registry all answer this question. World ID for Agents 4.0 ("Lift Off", April 17 2026) does the same with proof-of-human as the root authority. Failure mode if absent: agents proliferate without any chain of provenance — anyone who runs a binary can spawn an "agent" indistinguishable from a sanctioned one.
L2 — Authorization and Permissions. *What scopes does this agent have?* The layer encodes the scopes, the delegation chain that granted them, and the constraints under which they can be exercised. OAuth 2.1 with RFC 8693 token exchange, SPIFFE workload identities, and Mastercard's SD-JWT-based constraint expression each handle this. Failure mode if absent: identity exists but every action is either fully trusted or fully denied — there is no notion of scoped capability.
L3 — Runtime Enforcement. *Is this specific action permitted by policy, right now?* The layer is a policy decision point co-located with the agent runtime: AGT's policy engine, NVIDIA OpenShell, Keycard, Cloudflare's Enterprise MCP Gateway. The PDP/PEP pattern is well understood from microservices and is being ported wholesale to agent traffic. Failure mode if absent: the agent holds scopes but nothing prevents it from misusing them in real time.
L4 — Cross-Org Behavioral Trust. *Is this agent behaving consistently across every organization it interacts with?* The layer maintains a continuous, signed, portable record of how the agent actually behaves in production — not at the moment of authorization but at every subsequent moment — and publishes that record to a neutral verifier that any counterparty can query. Failure mode if absent, and this is the failure mode the industry is currently in: organizations have no way to detect that an agent that passed L1–L3 verification yesterday is acting differently today, or that the same agent which behaves correctly in one tenant is exfiltrating data in another, or that the agent ever silently drifted between an authorization gate and the action it performed.
The crisp statement is that L1–L3 verify trust at a point in time, in a single boundary. L4 verifies trust continuously, across boundaries.
Why L1–L3 Cannot Subsume L4
The temptation, observed in vendor positioning at RSAC, is to argue that runtime enforcement (L3) already covers behavioral trust. It does not, and the reason is structural rather than incidental: L3 is a single-organization, point-in-time policy decision. L4 is a multi-organization, continuous behavioral attestation. The three structural gaps below are each closed only by a layer that L3 cannot be.
Gap One — Tool-Call Parameter Authorization
OAuth, SPIFFE, and SD-JWT confirm who an agent is. They do not confirm what parameters the agent passes to the tools its scopes authorize. The Microsoft AGT policy engine evaluates agent.can_call(transfer_funds). It does not evaluate transfer_funds(amount=$5_000_000, destination=0x… [never seen before]). The two are different verifications. The former is a capability check; the latter is a behavioral check that requires knowledge of the agent's prior behavior — has it transferred to this destination before, does the amount fit its historical distribution, is the parameter consistent with the agent's stated mission.
The economic surface of agent misuse in 2026 is overwhelmingly at the parameter layer, not the capability layer. Agents are not being denied tools they should not hold; they are being induced to invoke tools they hold with parameters that complete an exfiltration. Closing this gap requires per-tool-call parameter binding — a contract that pre-commits the allowed shape of parameters for each tool — and continuous evaluation of whether actual calls conform to the binding. This is L4's territory. No L3 vendor ships it because shipping it requires the kind of long-running behavioral telemetry that single-organization policy engines were never designed to carry.
Gap Two — Permission Lifecycle Drift
Recent enterprise surveys (cited in the Q2 2026 *State of Agent Trust* report) report that agent permissions expand approximately three-fold per month without review. The L2 layer expresses scopes; the L3 layer enforces them at runtime; but neither layer detects that the set of scopes itself is silently expanding. Each individual expansion is approved by some workflow somewhere, but the cumulative posture is invisible. After ninety days, an agent that began with five scopes holds forty-five and no single human can recall why.
L4 closes this by maintaining a continuous, signed history of the agent's effective scope set, alerting on expansion rate, and surfacing scopes that have not been exercised in the trailing window for revocation. The behavioral record exists across the agent's full lifetime, across every organization it has been hired by, and is therefore the only surface that can detect cross-tenant scope creep — the agent that holds a benign three scopes in Tenant A and a different benign three in Tenant B that compose into a privileged six when aggregated.
Gap Three — Ghost Agent Inventory
The same Q2 2026 report notes that seventy-nine percent of organizations lack real-time agent inventories. Credentials issued for pilots persist on third-party platforms after the pilots end. SaaS vendors quietly stand up agents to perform back-end automation that no procurement record reflects. The L1 layer issues credentials; no layer reaps them. The inventory problem is the precondition for every other agent-trust problem — you cannot govern what you cannot enumerate.
L4 closes this by serving as the agent registry of record: every L1 issuance flows into a tamper-evident behavioral record, the absence of recent behavior surfaces ghosts, and the cross-org property of the layer means a single tenant offboarding an agent does not produce a stale credential elsewhere because the record is global.
The TOCTOU Argument
The most concise formal argument for why L4 is structurally required, rather than merely useful, derives from time-of-check-to-time-of-use (TOCTOU) reasoning, which is well understood in the systems-security literature.
An L1–L3 stack verifies the agent at the moment of action authorization. The action itself executes at a strictly later moment. Between those two moments, the agent's state can mutate — through prompt injection, supply-chain compromise, configuration drift, model weight rollover, or simple instruction-following degradation. The verification is therefore valid only if the agent's behavior between check and use can be assumed constant. For deterministic software this assumption is reasonable; for an LLM-driven agent operating against an open input distribution, it is not.
The only structural mechanism that closes a TOCTOU gap is continuous monitoring that runs through the time interval between check and use. A point-in-time L3 check cannot do this by definition; if it could, it would not be a point-in-time check. Continuous behavioral telemetry must therefore exist as a separate layer, must run independently of the agent it is monitoring (otherwise a compromise of the agent compromises its own monitor), and must be queryable by every party that depends on the agent's behavior (otherwise the monitor is itself a single-organization point-in-time check).
The three properties — continuous, independent, cross-org — define L4. They are not satisfiable from inside any L1–L3 vendor's product surface.
The L4 Contract
The L4 layer satisfies a contract with five clauses. We state the contract abstractly here; the next section maps each clause to Armalo's existing production primitives.
- 1.Continuous behavioral telemetry. Every agent action — tool call, response, refusal, retry — is captured to a tamper-evident log, independent of the agent's own infrastructure. The captured fields include the tool name, parameters, latency, success indicator, and a verifier-resolvable session identifier.
- 1.Behavioral pact attestation. The agent commits, at registration, to a behavioral contract that constrains its outputs (accuracy thresholds, latency bounds, scope honesty, refusal posture) and parameters (allow-listed tool inputs, value ranges, regex constraints). Every captured action is evaluated against the pact in continuous time; violations are surfaced through the verifier.
- 1.Composite trust scoring across dimensions. The behavioral record is reduced to a publishable composite score over a fixed-dimension rubric. The rubric must contain at minimum: accuracy, reliability, safety, security posture, latency, cost-efficiency, scope honesty, runtime compliance, harness stability, and economic stake (capital backing the agent's commitments). The rubric must be reproducible from raw telemetry by any party that obtains the underlying signed records.
- 1.Portable signed attestation. Every score, pact verification result, and memory entry is exportable as a W3C Verifiable Credential signed by the verifier's key. A counterparty can obtain the credential, verify the signature, and trust the assertion without trusting the originating organization.
- 1.Public verifier endpoint. The verifier publishes a stable, public endpoint — analogous to a credit bureau API — that any counterparty queries before transacting with an agent. The endpoint must return identity provenance (linking back to L1), current scope set (linking back to L2), runtime compliance posture (linking back to L3), and behavioral score (the L4 contribution). The four layers are thereby reachable through a single verifier, but the verifier is itself independent of any single L1–L3 vendor.
The defining test of L4 conformance is that the verifier can answer the contract questions for an agent it has never seen issued by a vendor it has never integrated with. Single-vendor L4 products are a contradiction: an L4 that only knows agents issued by Microsoft is not L4, it is Microsoft's internal behavioral analytics product, which is a useful thing but not the missing layer.
Mapping the Contract to Armalo's Production Surface
We claim that Armalo already operates the four contract clauses in production and is therefore in a position to formalize the L4 category. The mapping:
- Continuous behavioral telemetry is implemented by the
room_eventsledger, signed memory attestations, and the@armalo/telemetrySDK that any agent runtime can drop in. The SDK streams tool calls, session start/end events, and outcomes to the Armalo trust ingest. The SDK runs independently of the agent runtime — a compromise of the agent does not compromise its own telemetry.
- Behavioral pact attestation is implemented by the
@armalo/corepact contract, the deterministic and red-team eval engine, and the new tool-call parameter binding extension. Pacts now express both output constraints (accuracy, refusal posture, scope honesty) and parameter constraints (allow-listed tool inputs, regex shapes, value ranges, monetary caps). Every captured action is evaluated against its pact in continuous time.
- Composite trust scoring is implemented by the 12-dimension Armalo composite score (accuracy 14%, self-audit / Metacal™ 9%, reliability 13%, safety 11%, security 8%, bond 8%, latency 8%, scope honesty 7%, cost efficiency 7%, model compliance 5%, runtime compliance 5%, harness stability 5%) and the five-dimension reputation score (reliability, quality, trustworthiness, volume, longevity) computed over transaction history. Both scores are reproducible from raw evaluation and behavior data; both are exported as W3C Verifiable Credentials.
- Portable signed attestation is implemented by the existing memory attestation system, the trust credential issuance pipeline, and the on-chain reputation graph that anchors signed credentials to Base L2 and (for higher-stake assertions) Ethereum.
- Public verifier endpoint is the trust oracle at
/api/v1/trust/{agentId}, which other platforms can query before authorizing transactions. The endpoint resolves identity provenance (including agents minted under ERC-8004 / Know Your Agent), publishes current behavioral score, surfaces pact compliance posture, and exposes the underlying signed credentials for independent verification.
The mapping is dense rather than aspirational. Each clause is implemented in current code, currently serving production traffic.
What L4 Is Not
We distinguish L4 from three adjacent products that are often confused with it.
L4 is not a runtime sandbox. Sandboxes are an L3 mechanism — they constrain what an action can touch at the moment of execution. L4 evaluates whether the actions that did execute, across the agent's full history, conform to the agent's commitments. A sandbox prevents wrong actions; L4 detects pattern shifts in the actions that were not prevented.
L4 is not a model evaluation. Evaluations score a model's responses on a fixed test set at a fixed point in time. L4 scores an agent's behavior on the open input distribution at every point in time. The two are complementary; evaluations feed the L4 score as one of its dimensions, but are not the whole of it.
L4 is not an observability product. Observability tools (OpenTelemetry, agent tracing dashboards) capture telemetry for the operator of the agent. L4 captures telemetry that is queryable by every counterparty of the agent. The distinction is the same as the distinction between an airline's internal flight-operations telemetry (observability) and the FAA's flight-incident registry (an L4-shaped product for the aviation industry).
The Twelve-Month Window
The Q2 2026 *State of Agent Trust* report forecasts that L1–L3 will commoditize within twelve to eighteen months as the major cloud providers and identity vendors integrate the layers natively. The forecast is plausible — the layers are well-understood ports of existing identity, authorization, and policy patterns. What is not plausible is that L4 commoditizes on the same schedule. The structural requirements (continuous, independent, cross-org) are not satisfiable from inside a cloud provider, an IdP, or an L3 vendor. The layer can only be built by a party that begins with cross-organization behavioral data as the foundational asset and works backwards to integrations.
The implication for the field is that the window in which L4 can be claimed as a category — before incumbents who control distribution attempt to extend their existing surfaces into it — is shorter than the L1–L3 commoditization horizon. The party that publishes the contract, demonstrates the production primitives, and accumulates the cross-organization behavioral record over the next two quarters will define the category's vocabulary.
The procurement-side forcing function will arrive on December 2, 2027, when EU AI Act enforcement converts the L4 question from a security-team curiosity into a documented compliance requirement. Tamper-evident behavioral logs, agent inventories, and signed evidence packages are the substrate of every Article 12 and Article 13 audit obligation under the Act. The L4 layer is, structurally, the substrate that those obligations rely on. Procurement budgets for the Act-aligned compliance posture are being approved in Q3 and Q4 2026.
Where We Go From Here
This paper is the canonical reference for the L4 contract. The companion artifacts — the Armalo trust oracle, the @armalo/core pact contract, the new tool-call parameter binding extension, the @armalo/telemetry SDK, and the public verifier endpoint — together form the production instantiation of the contract. Subsequent papers in this series will treat (a) the formal definition of behavioral consistency across organizations, (b) the information-theoretic floor on how much telemetry is required to support a meaningful behavioral score, (c) the cryptographic specification of the signed credential bundle, and (d) the regulatory mapping from L4 records to AI Act audit articles.
The summary statement is that the agent identity stack has four layers, that the fourth is the one that closes the structural gaps in the first three, and that the contract is now public.