Independent Submission R. Sharif Internet-Draft CyberSecAI Ltd Intended status: Informational 15 April 2026 Expires: 17 October 2026 Agent Event Behaviour Analysis (AEBA): A Framework for Behavioural Security Monitoring of Autonomous AI Agents draft-sharif-aeba-00 Abstract This document specifies Agent Event Behaviour Analysis (AEBA), a framework for collecting, signing, exchanging, and analysing behavioural events produced by autonomous AI agents. AEBA is the agent-domain equivalent of User and Entity Behaviour Analytics (UEBA) as commonly deployed in enterprise Security Operations Centres. It defines a canonical event schema, signature binding to agent identity, baseline and peer-group exchange protocols, deviation signalling, detection rule structure, revocation mechanisms, and interoperability bindings for existing Security Information and Event Management (SIEM) event formats (syslog, CEF, LEEF). The framework is designed to compose with existing cryptographic primitives for agent identity, payment, and transport security, and to support cross-framework deployments in which agents produced by different runtimes must share a common behavioural observability surface. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 17 October 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Sharif Expires 17 October 2026 [Page 1] Internet-Draft AEBA April 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Relation to other drafts . . . . . . . . . . . . . . . . 4 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 3. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. In-scope threats . . . . . . . . . . . . . . . . . . . . 6 3.1.1. T1. Identity compromise . . . . . . . . . . . . . . 6 3.1.2. T2. Insider-style Agent misbehaviour . . . . . . . . 6 3.1.3. T3. Supply-chain compromise causing drift . . . . . 6 3.1.4. T4. Sybil agents . . . . . . . . . . . . . . . . . . 7 3.1.5. T5. Event forgery . . . . . . . . . . . . . . . . . 7 3.1.6. T6. Event suppression . . . . . . . . . . . . . . . 7 3.1.7. T7. Baseline poisoning . . . . . . . . . . . . . . . 7 3.1.8. T8. Peer-group spoofing . . . . . . . . . . . . . . 8 3.1.9. T9. Detection evasion via context-window manipulation . . . . . . . . . . . . . . . . . . . . 8 3.1.10. T10. Cross-host replay . . . . . . . . . . . . . . . 8 3.1.11. T11. Time skew attacks . . . . . . . . . . . . . . . 8 3.1.12. T12. Metadata smuggling . . . . . . . . . . . . . . 8 3.1.13. T13. Delegation-chain abuse . . . . . . . . . . . . 9 3.2. Out-of-scope threats . . . . . . . . . . . . . . . . . . 9 4. AEBA Architecture . . . . . . . . . . . . . . . . . . . . . . 9 5. Event Schema . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Mandatory fields . . . . . . . . . . . . . . . . . . . . 10 5.2. Envelope fields . . . . . . . . . . . . . . . . . . . . . 11 5.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.4. Event type categories . . . . . . . . . . . . . . . . . . 11 6. Signing and Identity Binding . . . . . . . . . . . . . . . . 12 6.1. Canonical form . . . . . . . . . . . . . . . . . . . . . 12 6.2. Signature algorithms . . . . . . . . . . . . . . . . . . 12 6.3. Identity binding . . . . . . . . . . . . . . . . . . . . 13 7. Baseline and Peer-Group Model . . . . . . . . . . . . . . . . 13 7.1. Baselines . . . . . . . . . . . . . . . . . . . . . . . . 13 7.2. Baseline fields . . . . . . . . . . . . . . . . . . . . . 13 7.3. Peer-group model . . . . . . . . . . . . . . . . . . . . 14 7.4. Baseline exchange . . . . . . . . . . . . . . . . . . . . 14 8. Deviation Signalling . . . . . . . . . . . . . . . . . . . . 14 8.1. Per-event score . . . . . . . . . . . . . . . . . . . . . 14 Sharif Expires 17 October 2026 [Page 2] Internet-Draft AEBA April 2026 8.2. Sequence score . . . . . . . . . . . . . . . . . . . . . 15 8.3. Signalling format . . . . . . . . . . . . . . . . . . . . 15 9. Detection Rules and Kill-Chain Patterns . . . . . . . . . . . 15 9.1. Mandatory rule categories . . . . . . . . . . . . . . . . 15 9.2. Rule interchange . . . . . . . . . . . . . . . . . . . . 16 10. Revocation Protocol . . . . . . . . . . . . . . . . . . . . . 16 11. Federation and Cross-Host Exchange . . . . . . . . . . . . . 17 12. Interoperability Bindings . . . . . . . . . . . . . . . . . . 17 12.1. Syslog (RFC 5424) . . . . . . . . . . . . . . . . . . . 17 12.2. CEF (Common Event Format) . . . . . . . . . . . . . . . 17 12.3. LEEF (Log Event Extended Format) . . . . . . . . . . . . 18 13. Security Considerations . . . . . . . . . . . . . . . . . . . 18 13.1. Signing is mandatory . . . . . . . . . . . . . . . . . . 18 13.2. Freshness and replay . . . . . . . . . . . . . . . . . . 18 13.3. Key management . . . . . . . . . . . . . . . . . . . . . 18 13.4. Baseline integrity . . . . . . . . . . . . . . . . . . . 18 13.5. Detection evasion . . . . . . . . . . . . . . . . . . . 18 13.6. Supply-chain threats . . . . . . . . . . . . . . . . . . 18 13.7. Abuse of AEBA data . . . . . . . . . . . . . . . . . . . 19 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 15.1. AEBA Event Type Registry . . . . . . . . . . . . . . . . 19 15.2. AEBA Signing Algorithm Registry . . . . . . . . . . . . 20 15.3. Rule Interchange Format . . . . . . . . . . . . . . . . 20 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 17.1. Normative References . . . . . . . . . . . . . . . . . . 20 17.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. Worked Example: Detecting Prompt-Injection-Driven Drift . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix B. Worked Example: Detecting Payment Rail Shift Attack . . . . . . . . . . . . . . . . . . . . . . . . . 22 Appendix C. Baseline Aggregation Canonical Form . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction Autonomous AI agents are being deployed into production in increasing numbers across payments, customer service, software engineering, healthcare, and industrial control. Enterprise Security Operations Centres have mature frameworks for monitoring the behaviour of human users through User and Entity Behaviour Analytics (UEBA) systems [UEBA-Gartner], but no equivalent standard exists for agent entities. This gap is becoming acute: agents operate at one to three orders of magnitude higher event rates than human users, carry cryptographic rather than password-based identities, and are subject to novel attack classes including prompt injection, delegation-chain abuse, and model-output-driven drift that have no human analogue. Sharif Expires 17 October 2026 [Page 3] Internet-Draft AEBA April 2026 This document defines a framework called Agent Event Behaviour Analysis (AEBA). AEBA specifies: * A canonical, extensible event schema for agent behavioural telemetry. * Binding of each event to a verifiable agent identity using existing cryptographic primitives. * A baseline-exchange protocol enabling hosts and observers to share per-agent normal-behaviour models. * A deviation-signalling mechanism producing per-event and per- sequence risk scores. * A detection-rule structure aligned with kill-chain pattern matching as practised in UEBA. * A revocation protocol for publishing cryptographic signals that a specific agent has been confirmed as misbehaving. * Interoperability bindings to syslog [RFC5424], CEF [CEF], and LEEF [LEEF], enabling direct ingestion by existing SIEM products. AEBA does not specify a complete SIEM or replace existing commercial offerings. It defines the common contract above which multiple vendors, open-source projects, and enterprise deployments can interoperate. 1.1. Relation to other drafts AEBA is designed to compose with, not replace, existing work on agent security: * Agent identity and key binding are specified by [I-D.sharif-agent-identity-framework]. * Event signing uses the same canonical-signing-string construction as [I-D.sharif-mcps-secure-mcp] and [I-D.sharif-agent-payment-trust]. * Per-message audit log format is specified by [I-D.sharif-agent-audit-trail]; AEBA events are a specific subtype suitable for behavioural analysis. * Runtime attestation of agent state is specified by [I-D.sharif-attp-agent-trust-transport] and provides supplementary input to AEBA detection. Sharif Expires 17 October 2026 [Page 4] Internet-Draft AEBA April 2026 AEBA is complementary to, not dependent on, OWASP [OWASP-AST10] and [OWASP-MCP10] risk taxonomies, and provides a machine-readable observability layer on which those risk categories can be monitored in production. 2. Terminology and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. The following terms are used throughout this document: Agent: An autonomous or semi-autonomous software entity executing under a runtime (for example, a Large Language Model with attached tools) that performs actions on behalf of a user, organisation, or other agent. AEBA Event: A structured, cryptographically signed record describing a single observable action taken by or on behalf of an Agent. Defined in Section 5. Baseline: A statistical model of the normal behaviour of an Agent or a peer-group of Agents over a specified time window. Defined in Section 7. Deviation Signal: A per-event or per-sequence risk score indicating the extent to which observed behaviour deviates from the applicable Baseline. Detection Rule: A declarative specification matching one or more AEBA Events against a known malicious pattern. Defined in Section 9. Peer Group: A set of Agents sharing a common purpose, deployment, framework, or role, against which individual Agent behaviour is compared. Host Runtime: The environment in which an Agent executes and which is responsible for emitting AEBA Events describing Agent actions. Collector: An AEBA role that receives AEBA Events from one or more Host Runtimes, verifies signatures, deduplicates, and forwards to one or more Analysers or SIEM systems. Analyser: An AEBA role that computes Baselines, applies Detection Sharif Expires 17 October 2026 [Page 5] Internet-Draft AEBA April 2026 Rules, and emits alerts. Trust Registry: An external authoritative endpoint that publishes and receives revocation signals for Agent identities, as specified by a referenced registry protocol. Consumer: A downstream recipient of AEBA alerts or raw events, typically a Security Operations Centre, an incident-response workflow, or a policy-enforcement engine. 3. Threat Model This section enumerates the threats AEBA is designed to detect or mitigate. Each threat is mapped to the AEBA mechanism addressing it. 3.1. In-scope threats 3.1.1. T1. Identity compromise An adversary obtains an Agent's signing key and emits actions indistinguishable from the legitimate Agent. AEBA mitigation: Baseline deviation. A compromised identity performing actions outside the legitimate Agent's behavioural envelope triggers Deviation Signals. Revocation via the Trust Registry halts further acceptance. 3.1.2. T2. Insider-style Agent misbehaviour A legitimately deployed Agent, under the effect of prompt injection, context poisoning, supply-chain-compromised dependency, or adversarial orchestration, performs actions outside its intended scope. AEBA mitigation: Behavioural-layer signals (see Section 8) detect deviations from the Agent's own baseline and from its peer-group baseline. Pattern-matching Detection Rules map known attack chains to alert conditions. 3.1.3. T3. Supply-chain compromise causing drift A legitimate Agent's dependencies, Skills, or underlying model are replaced with malicious versions; Agent behaviour subsequently drifts. Sharif Expires 17 October 2026 [Page 6] Internet-Draft AEBA April 2026 AEBA mitigation: Abrupt baseline shift not preceded by a signed deployment event triggers Deviation Signal. Event schema requires deployment-change events to be emitted and signed, enabling distinction between legitimate change and unauthorised drift. 3.1.4. T4. Sybil agents An adversary creates multiple agent identities to evade per-identity rate limits, spread malicious actions across identities, or forge peer-group support. AEBA mitigation: Peer-Group membership requires cryptographic attestation signed by an authority recognised by Consumers. Rapid creation of many new Agent identities from a single keyholder triggers Detection Rules. 3.1.5. T5. Event forgery An adversary injects fake AEBA Events into a Collector in order to mislead baseline computation or to pollute audit records. AEBA mitigation: All AEBA Events MUST be signed. Collectors MUST verify signatures before forwarding. Unsigned or invalidly-signed Events are rejected and themselves logged as a threat indicator. 3.1.6. T6. Event suppression An adversary suppresses AEBA Events to hide malicious behaviour, either at the Host Runtime, in transit, or at the Collector. AEBA mitigation: Sequential AEBA Events MUST include a monotonic per- Agent sequence number and a hash reference to the previous signed Event (the Agent Event Chain). Gaps, non-monotonic sequences, or broken chain references trigger Detection Rules. 3.1.7. T7. Baseline poisoning An adversary gradually shifts an Agent's baseline through low- deviation-per-event behaviour in order to render later malicious behaviour indistinguishable from the new normal. AEBA mitigation: Baselines MUST retain a long-term reference distribution distinct from the short-term rolling baseline. Significant divergence between short-term and long-term baselines is itself a Detection Rule signal. Peer-group comparison provides an independent reference resistant to per-Agent poisoning. Sharif Expires 17 October 2026 [Page 7] Internet-Draft AEBA April 2026 3.1.8. T8. Peer-group spoofing An Agent falsely claims membership in a trusted peer group to benefit from the more permissive baseline of that group. AEBA mitigation: Peer-Group membership attestations MUST be signed by a recognised authority, verified by Analysers, and revocable. 3.1.9. T9. Detection evasion via context-window manipulation A compromised Agent observes or infers detection thresholds and crafts behaviour to remain below them. AEBA mitigation: Detection Rules SHOULD incorporate randomised sampling and non-deterministic threshold components to frustrate modelling. Analysers MUST NOT publish detection thresholds to Agents. 3.1.10. T10. Cross-host replay An adversary captures signed Events from Host Runtime A and replays them into the Collector serving Host Runtime B. AEBA mitigation: AEBA Events MUST include Host Runtime identifier and a nonce; Collectors MUST reject duplicates and mismatched host bindings. 3.1.11. T11. Time skew attacks An adversary manipulates timestamps to alter sequence interpretation or to replay stale events. AEBA mitigation: Events MUST carry UTC timestamps; Analysers MUST reject events outside a configurable freshness window (recommended: +/-300 seconds) at ingestion, subject to explicit backfill procedure. 3.1.12. T12. Metadata smuggling An adversary uses Event metadata fields (labels, tags) to smuggle encoded data (exfiltration channel). AEBA mitigation: Metadata fields MUST be subject to schema validation and per-field length limits. Analysers SHOULD compute entropy statistics over metadata fields and alert on outlier entropy. Sharif Expires 17 October 2026 [Page 8] Internet-Draft AEBA April 2026 3.1.13. T13. Delegation-chain abuse A parent Agent spawns a child Agent that performs actions the parent's own policy would have denied. AEBA mitigation: Delegation events MUST be emitted and signed (parent-signs-child). Child Agent capability scope MUST NOT exceed parent Agent's scope; Analysers MUST enforce scope-inheritance limits and alert on violations. 3.2. Out-of-scope threats AEBA does not address: * Loss of confidentiality in Agent model internals (a model- protection problem); * Denial of service at the Host Runtime or Collector layer (handled by conventional network and infrastructure controls); * Physical-layer compromise of signing key storage (addressed by hardware security module practice). 4. AEBA Architecture The AEBA architecture comprises five roles. +---------+ +-----------+ +-----------+ | Agent |---->| Host |--->| Collector | +---------+ | Runtime | +-----------+ +-----------+ | v +-----------+ | Analyser | +-----------+ | | +-----------------+ +-----------+ v v +----------------+ +-----------------+ | Trust Registry | | SIEM / Consumer | +----------------+ +-----------------+ Role descriptions: 1. The *Agent* performs actions. Its runtime-observable actions produce AEBA Events. Sharif Expires 17 October 2026 [Page 9] Internet-Draft AEBA April 2026 2. The *Host Runtime* observes Agent actions and emits signed AEBA Events. It MAY perform this signing itself or it MAY forward Agent-self-signed Events. 3. The *Collector* receives Events from one or more Host Runtimes, verifies signatures, deduplicates, and forwards. 4. The *Analyser* computes Baselines, applies Detection Rules, and emits alerts. 5. The *Trust Registry* publishes revocation and peer-group attestation signals; the Analyser consults the Registry when evaluating identity binding. Any AEBA implementation MAY combine these roles. The protocol defines the contract between roles; it does not prescribe deployment topology. 5. Event Schema An AEBA Event is a JSON object with the following mandatory fields and an extensible set of optional type-specific fields. 5.1. Mandatory fields * aeba: (string) protocol version. Current value: "1.0". * id: (string) UUID v4 uniquely identifying this Event. * agentId: (string) identifier of the Agent, matching the keyid field in the signature envelope. * hostRuntimeId: (string) identifier of the Host Runtime from which the Event originated. * ts: (integer) Event timestamp in seconds since Unix epoch (UTC). * seq: (integer) monotonically increasing per-Agent sequence number. * prevHash: (string) hex-encoded SHA-256 digest of the canonical form of the previous Event emitted by this Agent, or 64 zeros for the first Event. * type: (string) Event type, drawn from the registered AEBA Event Type registry (see Section 15). * category: (string) one of "identity", "tool", "payment", "skill", "delegation", "deployment", "compliance", "custom". Sharif Expires 17 October 2026 [Page 10] Internet-Draft AEBA April 2026 * payload: (object) type-specific fields. 5.2. Envelope fields The signed envelope wrapping the Event contains: * alg: (string) signing algorithm identifier. Initial values: "ES256" (mandatory-to-implement). * keyid: (string) identifier of the signing key. * sig: (string) base64-encoded signature over the canonical form (see Section 6). * pubkeyHint: (string, optional) URL at which the verification key may be retrieved. 5.3. Example { "aeba": "1.0", "id": "7c6e5b94-f8a1-4e9d-a3c2-b0d7f2e1c5a8", "agentId": "agent:acme-payments-01", "hostRuntimeId": "host:prod-us-east-cluster-7", "ts": 1744746000, "seq": 14823, "prevHash": "3f4a8b2c1d7e9f0a6b5c4d3e2f1a0b9c...", "type": "tool.call", "category": "tool", "payload": { "toolName": "agentpass_pay", "toolArgs": { "rail": "x402", "to": "merchant-hash:8a7f...", "amount": 2500, "currency": "USD" }, "durationMs": 142, "outcome": "allowed" } } 5.4. Event type categories Each AEBA Event MUST declare a category. Categories are: * identity -- Agent identity events: keypair issuance, key rotation, credential verification, delegation issuance. Sharif Expires 17 October 2026 [Page 11] Internet-Draft AEBA April 2026 * tool -- Tool invocation events: tool call, tool response, tool selection decision. * payment -- Payment-related events: payment initiated, payment settled, sanctions check performed. * skill -- Skill events: skill loaded, skill verified, skill rejected. * delegation -- Agent-to-agent events: child agent spawn, delegated authority issued, delegated authority exercised. * deployment -- Runtime environment change events: code deployed, dependency updated, model version change. * compliance -- External compliance signals: KYC completed, AML check, regulatory report. * custom -- Implementation-specific events. Custom events MUST use reverse-DNS-scoped type names to prevent collision. 6. Signing and Identity Binding AEBA Events MUST be cryptographically signed. The signing scheme reuses the canonical-signing-string construction of [I-D.sharif-mcps-secure-mcp] and [I-D.sharif-agent-payment-trust] to enable shared verification infrastructure. 6.1. Canonical form The canonical form of an AEBA Event for signing is: Where canonical-json(event) is the JCS-canonicalised JSON form of the Event object, and fields are joined by single space characters. 6.2. Signature algorithms The mandatory-to-implement algorithm is ECDSA P-256 with SHA-256 (JWA ES256) as defined in [RFC7518]. Implementations MAY support additional algorithms consistent with existing agent-identity stacks (for example, Ed25519). Sharif Expires 17 October 2026 [Page 12] Internet-Draft AEBA April 2026 6.3. Identity binding The keyid field in the signature envelope MUST equal the agentId field in the Event body, or MUST be a designated signing key for that Agent as registered with the applicable Trust Registry. Host Runtimes that sign Events on behalf of Agents (server-side signing) MUST carry a signedBy field in the envelope distinguishing the signing identity from the Agent identity, and MUST bind the Host Runtime signing key to the Agent's declared Host Runtime via the Trust Registry. 7. Baseline and Peer-Group Model 7.1. Baselines A Baseline is a statistical model of normal behaviour for an Agent or Peer Group over a given time window. AEBA defines two baseline classes: * *Short-term baseline*: rolling window (recommended: 24 hours). Sensitive to recent behaviour; used for near-real-time anomaly scoring. * *Long-term baseline*: reference window (recommended: 90 days). Resistant to short-term drift; used for detecting baseline poisoning (see Section 3.1.7). Implementations MUST maintain both classes and MUST compute deviation against both. 7.2. Baseline fields A minimal Baseline record comprises: * eventRatePerMinute: distribution (mean, stddev, p50, p95, p99) * eventCategoryMix: distribution across categories * toolDiversity: distinct tools invoked per unit time * costPerTask: distribution of token / compute cost per logical task * paymentRecipientConcentration: Herfindahl index or equivalent * peerGroupMembership: attested group(s) Sharif Expires 17 October 2026 [Page 13] Internet-Draft AEBA April 2026 * operationalSchedule: if applicable (distributions by hour-of-day, day-of-week) Implementations MAY extend this set; extensions MUST use reverse-DNS scoping. 7.3. Peer-group model A Peer Group is a named set of Agent identities plus an authority attestation signed by a recognised Peer-Group authority. The attestation MUST specify: * peerGroupId: stable identifier * purpose: human-readable group purpose * members: list of agentId values in the group * issuedBy: identifier of attesting authority * validFrom / validUntil: validity window * attestation: signature by the authority Peer-Group authorities are trust anchors; their identity and authorisation MUST be established out of band (typically by the Trust Registry operator). 7.4. Baseline exchange Baselines MAY be exchanged between Host Runtimes and Analysers so that an Agent deployed in multiple environments carries its behavioural history with it. Baseline-exchange messages MUST be signed by the emitting party, MUST include a validity window, and MUST reference the constituent Agent or Peer Group identifiers. 8. Deviation Signalling For each incoming Event, the Analyser computes a deviation score bounded in [0.0, 1.0] where 0.0 denotes behaviour identical to baseline and 1.0 denotes maximal deviation observed during the baseline window. 8.1. Per-event score The per-event deviation score is a weighted composite over: * Event rate component (current rate vs baseline distribution) Sharif Expires 17 October 2026 [Page 14] Internet-Draft AEBA April 2026 * Category-mix component (divergence of current category from expected) * Tool-choice component (likelihood of tool selection under baseline) * Peer-group component (agreement of Event with peer baseline) The weighting is implementation-defined; implementations SHOULD document the weighting and MUST publish it to Consumers for audit. 8.2. Sequence score Sequences of Events are scored collectively against Detection Rules (see below). Sequence scores are not bounded to [0.0, 1.0]; they are Rule-defined alert conditions. 8.3. Signalling format Deviation and alert signals are themselves AEBA Events with category "custom" and reverse-DNS type names such as com.example.aeba.alert. They are signed by the Analyser and forwarded to Consumers. 9. Detection Rules and Kill-Chain Patterns Detection Rules are declarative specifications of known malicious patterns. A Detection Rule comprises: * ruleId: stable identifier (reverse-DNS scoped) * description: human-readable description * scope: applicable Agent categories or peer groups * pattern: pattern specification (event sequence, rate, divergence) * severity: "low" | "medium" | "high" | "critical" * action: recommended Consumer action on match 9.1. Mandatory rule categories Implementations MUST support at least the following rule categories: * *Identity-layer*: signature failures, concurrent-keyid detection, rotation-frequency anomalies. Sharif Expires 17 October 2026 [Page 15] Internet-Draft AEBA April 2026 * *Behavioural-layer*: event-rate spike, tool-diversity spike, category-mix shift. * *Economic-layer*: payment-velocity anomaly, rail-mix shift, recipient-concentration spike, failed-payment rate. * *Relational-layer*: delegation-depth anomaly, sub-agent spawn rate, cross-framework interaction. * *Compliance-layer*: sanctions-match rate, KYC-failure rate, trust score degradation. 9.2. Rule interchange Detection Rules are exchanged between parties as signed JSON documents. The interchange format is defined in Section 15.3. 10. Revocation Protocol When an Agent is confirmed as misbehaving, the applicable Trust Registry MUST issue a revocation signal. AEBA revocation signals MUST: * be signed by the Trust Registry authority; * name the revoked Agent keyid; * specify revocation scope: "all_events", "future_events_only", or "specific_type:"; * specify effective time (revokedFrom); * specify reason ("key_compromise", "malicious_behaviour", "policy_violation", "retired"). Consumers MUST check revocation state for each Agent either at Event- ingestion time (strict) or at alert-evaluation time (lazy). Implementations SHOULD maintain a local cache with a maximum freshness of 24 hours for high-criticality flows and 7 days otherwise. Revocation cascades follow delegation chains: revocation of a parent Agent keyid MUST cause implicit revocation of all descendants. Sharif Expires 17 October 2026 [Page 16] Internet-Draft AEBA April 2026 11. Federation and Cross-Host Exchange AEBA supports federated deployments in which Agents move between Host Runtimes operated by different organisations (for example, a Skill published centrally and invoked locally). Federation SHALL use: * cross-host baseline exchange as defined above; * Trust Registry references resolvable via HTTPS; * mutual attestation between federating Host Runtimes. Federated Consumers SHOULD NOT rely on unsigned baseline imports. 12. Interoperability Bindings 12.1. Syslog (RFC 5424) AEBA Events MAY be emitted as Syslog [RFC5424] messages. The APP- NAME MUST be "aeba". Structured data MUST include the AEBA Event JSON as a single SD-ELEMENT: <14>1 2026-04-15T08:00:00Z host.example aeba - AEBA [aeba@99999 event="" sig=""] AEBA event 12.2. CEF (Common Event Format) AEBA Events MAY be emitted as CEF records with: * Device Vendor: "AEBA" * Device Product: implementation name * Device Version: protocol version ("1.0") * Signature ID: AEBA Event type * Name: human-readable Event description * Severity: mapped from deviation score (0-10) Structured AEBA fields MUST be carried in CEF extension fields using reverse-DNS naming. Sharif Expires 17 October 2026 [Page 17] Internet-Draft AEBA April 2026 12.3. LEEF (Log Event Extended Format) AEBA Events MAY be emitted as LEEF records following the same field conventions as CEF. 13. Security Considerations AEBA is itself a security-critical protocol. The following considerations apply. 13.1. Signing is mandatory All AEBA Events MUST be signed. Unsigned events compromise the entire analytical model and MUST be rejected at ingestion. 13.2. Freshness and replay Events MUST include a timestamp and sequence number. Analysers MUST reject events outside a freshness window (recommended: +/-300 seconds) and MUST reject replayed prevHash sequences. 13.3. Key management Agent signing keys MUST be stored in accordance with host platform best practice (hardware security module, enclave, OS keystore). Loss of a signing key MUST trigger revocation. 13.4. Baseline integrity Baselines are themselves security-critical artifacts. Exchange between parties MUST be signed. Long-term baselines MUST be preserved through key rotation and custodial transitions. 13.5. Detection evasion Implementations MUST NOT publish detection thresholds or rule weightings to unauthenticated parties. Detection Rule interchange MUST be between trusted parties. 13.6. Supply-chain threats AEBA cannot detect Agent behaviour that is permanently within baseline but intrinsically malicious. AEBA is a complement to, not a replacement for, pre-deployment supply-chain verification (Skill signing, model attestation, dependency verification). Sharif Expires 17 October 2026 [Page 18] Internet-Draft AEBA April 2026 13.7. Abuse of AEBA data AEBA Events describing Agent actions may reveal sensitive information about the Agent's operator, the Agent's users, or downstream systems. Access to AEBA data MUST itself be access-controlled and auditable. 14. Privacy Considerations AEBA Events can contain personally identifiable information (PII) and confidential business data, including customer identities, payment recipients, document contents, and authentication artifacts. Implementations MUST: * minimise PII in Event payloads, preferring hashed or tokenised identifiers where correlation is sufficient; * apply encryption at rest to AEBA stores; * implement retention policies consistent with applicable regulation (for example, GDPR Article 5(1)(e), CCPA, UK Data Protection Act); * support the right of erasure (where legally required) by cryptographic redaction of AEBA stores, recognising that signed chain integrity may be partially lost on erasure. Baselines themselves are subject to privacy analysis. A Baseline may reveal aggregate user behaviour patterns and SHOULD be treated as confidential. 15. IANA Considerations This document requests IANA to establish two new registries. 15.1. AEBA Event Type Registry A registry named "AEBA Event Types" with the following columns: * type: the event type string (e.g., "tool.call", "payment.initiated") * category: one of the defined categories * description: human-readable description * reference: defining document Sharif Expires 17 October 2026 [Page 19] Internet-Draft AEBA April 2026 Registration policy: Specification Required for the reserved categories; First Come First Served for reverse-DNS-scoped custom types. Initial entries corresponding to the categories defined in Section 5. 15.2. AEBA Signing Algorithm Registry A registry named "AEBA Signing Algorithms" listing acceptable alg values. Initial entries: * ES256 -- ECDSA P-256 with SHA-256 (from [RFC7518], mandatory) * EdDSA -- Edwards-curve Digital Signature Algorithm (optional) 15.3. Rule Interchange Format IANA is requested to register a media type application/aeba-rule+json for the Detection Rule interchange format defined in this document. 16. References 17. References 17.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, . [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP Message Signatures", RFC 9421, DOI 10.17487/RFC9421, February 2024, . 17.2. Informative References Sharif Expires 17 October 2026 [Page 20] Internet-Draft AEBA April 2026 [UEBA-Gartner] Gartner, "Market Guide for User and Entity Behavior Analytics", 2023. [CEF] Micro Focus ArcSight, "Common Event Format", n.d.. [LEEF] IBM QRadar, "Log Event Extended Format (LEEF)", n.d.. [MITRE-ATTACK] MITRE Corporation, "MITRE ATT&CK Framework", n.d.. [OWASP-AST10] OWASP Foundation, "OWASP Agentic Skills Top 10", n.d.. [OWASP-MCP10] OWASP Foundation, "OWASP MCP Top 10", n.d.. [I-D.sharif-mcps-secure-mcp] Sharif, R., "MCPS: Cryptographic Security Layer for the Model Context Protocol", Work in Progress, Internet-Draft, draft-sharif-mcps-secure-mcp-00, 14 March 2026, . [I-D.sharif-agent-payment-trust] Sharif, R., "Trust Scoring and Identity Verification for Autonomous AI Agent Payment Transactions", Work in Progress, Internet-Draft, draft-sharif-agent-payment- trust-00, 25 March 2026, . [I-D.sharif-agent-audit-trail] Sharif, R., "Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems", Work in Progress, Internet- Draft, draft-sharif-agent-audit-trail-00, 29 March 2026, . [I-D.sharif-agent-identity-framework] Sharif, R., "Agent Identity Framework: Trust and Identity for Autonomous AI Agents", Work in Progress, Internet- Draft, draft-sharif-agent-identity-framework-00, 6 April 2026, . Sharif Expires 17 October 2026 [Page 21] Internet-Draft AEBA April 2026 [I-D.sharif-attp-agent-trust-transport] Sharif, R., "ATTP: Agent Trust Transport Protocol for Secure Agent-to-Server Communication", Work in Progress, Internet-Draft, draft-sharif-attp-agent-trust-transport- 00, 30 March 2026, . Appendix A. Worked Example: Detecting Prompt-Injection-Driven Drift This appendix illustrates AEBA in action against an attack described in Section 3.1.2 (Insider-style Agent misbehaviour). Scenario: An e-commerce Agent's baseline shows it calls payment.pay with rail=stripe 95% of the time, currency=USD 90% of the time, with amount distributed log-normally around $40. Average event rate: 8 per minute over business hours. Adversary injects a prompt that causes the Agent to attempt a rail=x402 payment to a newly-observed recipient, amount=$5000, repeatedly over 30 seconds. AEBA detection: 1. Per-event deviation score: the rail choice is a 5% rail with probability weight 0.05, producing high component score. 2. Recipient concentration: recipient is new to the agent; Herfindahl shift component adds further weight. 3. Event rate: 15 events in 30 seconds (30/min) vs baseline 8/min triggers rate rule. 4. Category-mix: normal mix has payment = 40%; this burst is payment = 100%; mix-shift rule triggers. 5. Composite sequence score exceeds alerting threshold; Analyser emits alert of severity "high" with recommended action "suspend_agent". Appendix B. Worked Example: Detecting Payment Rail Shift Attack [Illustration omitted for brevity; pattern follows that of the previous appendix but focused on Economic-layer detection.] Sharif Expires 17 October 2026 [Page 22] Internet-Draft AEBA April 2026 Appendix C. Baseline Aggregation Canonical Form [Specification of the canonical form for Baseline records, ensuring deterministic hashing and inter-party agreement. Omitted for the -00 draft.] Author's Address Raza Sharif CyberSecAI Ltd Email: raza.sharif@outlook.com Sharif Expires 17 October 2026 [Page 23]