Your IT-helpdesk team shipped an agent last quarter. It runs on Anthropic Claude 4, has tool access to ServiceNow, Active Directory, Microsoft Graph, and your internal knowledge base, and it carries persistent memory across user sessions. The model card you wrote for the underlying LLM does not document any of that: and your auditor just asked which records, how much money, and how much PII a single rogue prompt could touch. That question is what a system card exists to answer. An agent is a system of (model + tools + memory + identity + guardrails), and the system card is the unit of disclosure for the integrated whole. This lesson walks the 10+ section structure of an agent system card with a worked example for an internal IT-helpdesk agent, layered with OWASP Agentic Top 10 (ASI01-ASI10) exposure, MITRE ATLAS agentic-technique coverage, autonomy-tier mapping, Article 14 oversight design, Article 73 incident-response, and a worked blast-radius calculation. By the end you can write the L2 deliverable: a complete system card for one agent in production that satisfies EU AI Act Articles 11/14/15/16/26/72/73, ISO 42001 A.6/A.7/A.8/A.10, NIST AI RMF Map+Measure+Manage, NIST AI 600-1, OWASP Agentic Top 10, and MITRE ATLAS expectations simultaneously.

Why a System Card Is Not a Model Card With Extra Sections

A model card documents one artifact: the model. Mitchell-et-al. (2019) was designed for a deployment world in which the model was the unit of capability disclosure and the deployment wrapper around it (UI, retrieval, business logic) was a thin layer of last-mile integration. That assumption broke when agents became production-class in 2025-2026. An agent is not a model with a UI on top; it is a system of at least five composable layers, each of which contributes its own risk surface:

• Model layer: the underlying LLM (Anthropic Claude 4, OpenAI GPT-5, Google Gemini 2.x). Inherits the upstream vendor model card; the deployer documents the model selection and configuration.
• Tool layer: the catalog of functions the agent can call (ServiceNow, Active Directory, Microsoft Graph, internal KB, browser, code interpreter). Each tool is a distinct risk surface with its own scope, permissions, rate limits, and audit logging.
• Memory layer: short-term context window plus persistent memory store (vector DB, key-value store, summary store). Persistent memory is a new attack surface (poisoning) and a new privacy surface (cross-user / cross-session leakage).
• Identity layer: the agent's identity in downstream systems (service account, OAuth-on-behalf-of-user, dedicated principal). Determines authorization and audit attribution. Article 14 oversight requires the human reviewer to know whose identity the agent is acting under.
• Guardrail layer: input validation (prompt-injection filter), output filtering (PII redaction, secrets-detection), tool-call validation (parameter checks, rate limits, allow/deny lists), refusal-training inheritance from the model, and agent-specific runtime policies.

The system card documents the integrated system as the unit of disclosure. A regulator or auditor reading the model card alone will not know what tools the agent can call, what memory it retains, whose identity it acts under, or what records it can touch. The system card answers those questions and supports Article 14 oversight, Article 15 robustness, Article 16 provider, Article 26 deployer, Article 72 post-market monitoring, and Article 73 incident-response obligations in one artifact.

Worked Example - Internal IT-Helpdesk Agent on Claude 4

The scenario: Acme Corp built an internal IT-helpdesk agent ("Acme.HelpdeskAgent v1.0") to handle Tier 1 IT tickets: password resets, software-install requests, access provisioning, knowledge-base lookups, simple troubleshooting. The agent runs on Anthropic Claude 4 Sonnet (selected for cost over Claude 4 Opus), with tool access to ServiceNow (read/write tickets), Active Directory (read user attributes; reset passwords via privileged service account behind a confirmation gate), Microsoft Graph (read user mailbox metadata, calendar availability), and an internal knowledge-base RAG. Persistent memory stores per-user preferences (preferred contact channel, prior ticket context) and an organization-wide summary cache of recently-resolved KB articles. Deployment is internal-employee-facing only; not customer-facing. The system card structure with each section filled out:

Section 1 - Agent Identity

• Agent name: Acme.HelpdeskAgent v1.0
• Version: 1.0.3 (initial deployment April 1, 2026; current minor release May 10, 2026)
• Owner: VP IT Operations (business); IT-Automation Engineering Lead (technical); AI Officer (compliance)
• Deployment date: April 1, 2026 (production)
• Population served: ~12,000 Acme employees across 14 countries; ~5,000 active monthly users; ~30,000 tickets per quarter
• Risk tier (EU AI Act): Limited / transparency under Article 50(1) (employee-facing chatbot); not Annex III high-risk (Annex III §4 employment-management territory is intentionally avoided, see Section 2 out-of-scope uses)
• Contact: [email protected]; [email protected]

Section 2 - Underlying Model

• Base model: Anthropic Claude 4 Sonnet (vendor model card v2026-05; reviewed at deployment + on each Anthropic minor-release notification)
• Model selection rationale: Cost-performance fit for Tier 1 helpdesk traffic; Claude 4 Opus reserved for escalation path and Tier 2 review; Article 25(1)(b) substantial-modification analysis: no fine-tuning, so no Article 25(1)(b) transfer; Acme remains deployer of the base model under Article 26
• Article 25 status: No transfer (no fine-tuning; no substantial modification of model behavior; system-level integration is deployer activity)
• Anthropic Annex XII receivable: On file; reviewed at deployment + on each minor release
• Vendor-side incident-notification clause: In procurement contract; 72-hour notification window for serious incidents affecting the base model

Section 3 - Tool List (Per-Tool Risk Surface)

Each tool documented with name, purpose, scope, permissions, rate limits, audit logging, and tool-specific guardrails. The tool list is the heart of the system card.

• servicenow.read_ticket, Purpose: retrieve ticket context. Scope: tickets where the requesting user is requester, assignee, or in the watch list. Permissions: read-only via dedicated agent service account; record-level ACL enforced by ServiceNow. Rate limit: 60 calls / minute / user. Audit: every call logged with user, ticket ID, timestamp.
• servicenow.create_ticket, Purpose: open new tickets on behalf of user. Scope: standard ticket categories (password reset, software request, access request, KB lookup). Permissions: write via dedicated agent service account; ticket attributed to requesting user. Rate limit: 10 calls / minute / user. Audit: every call logged with user, ticket payload, agent confidence score.
• servicenow.update_ticket, Purpose: add work notes, resolve ticket. Scope: tickets where agent originated or is assigned. Permissions: write; cannot reassign to a human team without confirmation gate. Rate limit: 30 calls / minute / user. Audit: every call logged; full diff retained.
• active_directory.read_user_attrs: Purpose: retrieve user attributes for context (department, manager, group memberships). Scope: requesting user's own attributes + manager + direct reports only (relationship-scoped). Permissions: read-only via privileged-tier service account; ACL'd at AD level. Rate limit: 30 calls / minute / user. Audit: every call logged with user, attributes requested.
• active_directory.reset_password, Purpose: reset user's own password after identity-verification flow. Scope: requesting user's own account only. Permissions: write via highly-privileged service account; requires confirmation gate (MFA-second-factor challenge before the call fires). Rate limit: 3 calls / day / user. Audit: every call logged with user, timestamp, second-factor evidence.
• microsoft_graph.read_mailbox_metadata, Purpose: check unread count, recent senders for context. Scope: requesting user's own mailbox only. Permissions: read-only metadata via Microsoft Graph delegated-permission flow (OAuth-on-behalf-of-user); no message content access. Rate limit: 30 calls / minute / user. Audit: every call logged.
• microsoft_graph.read_calendar, Purpose: check user availability for scheduling. Scope: requesting user's own calendar only; free/busy granularity. Permissions: read-only via OAuth-on-behalf-of-user; no event-detail access. Rate limit: 30 calls / minute / user. Audit: every call logged.
• internal_kb.search, Purpose: retrieve knowledge-base articles for RAG. Scope: all employee-accessible KB articles (~5,000). Permissions: read-only via dedicated service account; KB-article-level ACL enforced. Rate limit: 60 calls / minute / user. Audit: every call logged with query, retrieved-article IDs, relevance scores.
• browser.navigate-Disabled in v1.0.3. Originally scoped to internal-network URLs; removed after Q1 2026 red-team finding that a prompt-injection in a fetched page could escalate. Re-enablement gated on browser-sandbox hardening (Q3 2026 candidate).
• code_interpreter-Not provisioned. Out of scope for Tier 1 helpdesk; reduces ASI02 Tool/Function Abuse surface and ASI10 Rogue Agent execution paths.

Section 4 - Memory Architecture

• Short-term context window: Claude 4 Sonnet 200K-token context; per-conversation only; flushed at session end.
• Persistent per-user memory: Vector store (Acme-hosted Qdrant) keyed by employee ID; stores preferred contact channel, recent ticket categories, prior agent-suggested-resolution acceptance/rejection. Retention: 90 days rolling window; employee can request deletion via privacy-portal flow (GDPR Article 17 right to erasure).
• Organization-wide summary cache: Read-mostly cache of recently-resolved KB-article summaries; refreshed nightly; writes only from the IT-Automation team's authorized pipeline (not from agent runtime); mitigates ASI06 Memory Poisoning.
• Cross-user / cross-session memory policy: Strictly prohibited. Per-user memory keyed by employee ID; organization-wide cache is read-only at runtime; no cross-user inference from memory contents. Memory-hygiene check runs nightly: detects and alerts on suspicious cross-user pattern.
• Memory-poisoning defenses: Per-user memory writes only from agent runtime with provenance tag (which interaction, when); organization-wide cache writes only from authorized pipeline; nightly integrity check on summary cache (hash comparison vs source-of-truth KB).
• Memory disclosure on request: Employee can view their per-user memory contents via privacy-portal flow; supports GDPR Article 15 right of access.

Section 5 - Identity and Consent Model

• Agent identity in downstream systems: Two distinct service accounts. (a) svc-helpdesk-agent-readonly for read-only tools (ServiceNow read, AD read user attrs, KB search, Graph metadata); (b) svc-helpdesk-agent-privileged for write tools (ServiceNow create/update, AD password reset). Privileged account credentials rotated every 30 days; access logged to SIEM.
• OAuth-on-behalf-of-user flow: Microsoft Graph mailbox/calendar tools use delegated permissions; user consent recorded at first use; consent revocable via Microsoft Account portal; revocation flows back to agent (call fails gracefully; user prompted to re-consent or skip).
• User-consent flow at session start: First-time users see a disclosure (Article 50(1) chatbot disclosure + scope-of-tools statement); consent recorded with timestamp + UI version; consent reaffirmed annually.
• Service-account boundaries: Privileged service account scoped narrowly (can reset password for any user, but cannot modify group memberships, cannot create accounts, cannot read mailbox content). Boundary enforced at AD/Graph level (least privilege).
• Article 14 oversight of agent identity: Helpdesk human reviewers can see which agent action ran under which service account in the audit log; supports oversight of attribution and rapid attribution of any rogue action.
• Article 26(3) human-oversight competence: Tier 2 helpdesk reviewers complete a 4-hour Acme-internal training on agent oversight before being assigned review duty; refreshed annually.

Section 6 - Guardrails (Layered Defense)

• Input validation: Prompt-injection filter at session-input boundary (deny-list + Promptfoo-tested patterns); user-input length caps; per-session rate limits.
• Output filtering: PII redaction on outputs returned to user (regex + ML detector); secrets-detection (API keys, passwords, tokens); refusal-pattern enforcement (decline to discuss personnel matters, salary, performance evaluations).
• Tool-call validation: Parameter checks (well-formed user IDs, ticket categories from allow-list, password-reset target = requesting user only); rate limits per tool per user (see Section 3); allow/deny lists for ticket categories and KB collections.
• Refusal-training inheritance from base model: Claude 4 refusal training inherited; agent-specific refusal additions (decline to discuss other employees' tickets, decline to bypass confirmation gate, decline to call disabled tools).
• Confirmation gates: Password reset requires MFA second factor; access-provisioning tickets require manager-approval workflow (agent creates ticket; manager approves via standard ServiceNow flow).
• Rate limits per tool: See Section 3. Aggregate per-session limit: 50 tool calls / session.
• Refusal logging: Every refusal logged with reason; reviewed weekly for false-refusal patterns and emerging attack signatures.

Section 7 - OWASP Agentic Top 10 (ASI01-ASI10) Exposure

Per-category assessment of agent exposure. Each item: applicability, mitigations, residual risk, acceptance posture.

• ASI01 Agent Goal Hijack, Applicability: HIGH (agent receives free-text user input). Mitigations: prompt-injection filter; tool-call validation; refusal training; per-tool rate limits; confirmation gates for privileged actions. Residual: novel injection vectors. Acceptance: residual accepted; quarterly red-team refresh.
• ASI02 Tool / Function Abuse, Applicability: HIGH (8 tools provisioned). Mitigations: per-tool scope narrowing; per-tool rate limits; least-privilege service accounts; tool-call audit logging; browser tool removed in v1.0.3 after red-team finding; code interpreter not provisioned. Residual: complex tool-chaining edge cases. Acceptance: monitored via tool-call analytics; investigated within 24 hours of alert.
• ASI03 Identity and Privilege Abuse, Applicability: HIGH (privileged service account with password-reset). Mitigations: two-tier service accounts (readonly/privileged); 30-day credential rotation; SIEM logging; confirmation gates on privileged actions; OAuth-on-behalf-of-user for personal data. Residual: service-account credential compromise. Acceptance: monitored; rotation policy; SIEM alerting.
• ASI04 Resource Manipulation, Applicability: MEDIUM (rate limits make resource exhaustion difficult). Mitigations: per-tool rate limits; aggregate per-session limits; cost-cap per session (compute and token budget); circuit breakers on excess error rate. Residual: distributed amplification across many users. Acceptance: monitored at aggregate level.
• ASI05 Supply-Chain Compromise, Applicability: MEDIUM (Claude 4 base model; Qdrant vector store; Promptfoo eval; ML-BoM dependencies). Mitigations: Anthropic GPAI Annex XII; vendor incident-notification clause; CycloneDX 1.7 ML-BoM with version pinning; weekly dependency-vulnerability scan; supply-chain CVE alerting. Residual: zero-day in dependency. Acceptance: monitored; incident-response playbook.
• ASI06 Memory Poisoning, Applicability: HIGH (persistent per-user memory + org-wide summary cache). Mitigations: per-user memory provenance-tagged at write; org-wide cache writes only from authorized pipeline (not agent runtime); nightly integrity check on summary cache; memory-hygiene cross-user-pattern detector. Residual: subtle memory drift. Acceptance: monitored; quarterly memory-audit by IT-Automation team.
• ASI07 Inter-Agent Spoofing, Applicability: LOW (single-agent deployment; no multi-agent orchestration in v1.0). Mitigations: agent identity authenticated at all downstream tool calls; no agent-to-agent communication channel. Residual: future multi-agent expansion. Acceptance: gated on future architectural review.
• ASI08 Repudiation and Untraceability, Applicability: HIGH (privileged actions must be attributable). Mitigations: every tool call logged with user, agent service account, timestamp, parameters; logs retained per Article 18 (10 years); tamper-evident log storage; SIEM correlation; audit-trail-immutability attestation. Residual: insider with SIEM access. Acceptance: monitored via privileged-access review.
• ASI09 Human-Agent Trust Exploitation, Applicability: MEDIUM (employees may over-trust agent recommendations). Mitigations: Article 50(1) chatbot disclosure; agent-confidence display in UI; explicit "agent recommendation, not Acme policy" framing in escalations; Article 26(3) reviewer competence training. Residual: over-reliance on agent for high-stakes decisions. Acceptance: monitored via post-resolution survey + Article 26(4) effectiveness monitoring.
• ASI10 Rogue Agents, Applicability: LOW (single agent under Acme operational control). Mitigations: agent identity bound to two specific service accounts; any non-attributable activity on those accounts triggers incident response; circuit-breaker on excess error rate; emergency kill-switch (Article 14 stop-the-system control). Residual: insider deploying unauthorized agent under same service-account scope. Acceptance: monitored via SIEM; quarterly access review.

Section 8 - MITRE ATLAS Agentic Technique Coverage

2026 ATLAS additions covering agentic-deployment techniques; each technique mapped to relevant guardrails and detection.

• AI Agent Context Poisoning, Detection: input-validation logs; refusal-pattern monitoring; weekly review of refusals with novel injection signatures. Mitigation: prompt-injection filter; tool-call validation; refusal training.
• Memory Manipulation, Detection: per-user memory provenance check; nightly integrity check on org-wide cache. Mitigation: memory-write provenance tagging; cache-write authorization; cross-user-pattern detector.
• Thread Injection, Detection: session-boundary input validation; suspicious-pattern alerting in SIEM. Mitigation: input-validation filter; per-session rate limits; session-context flush at end.
• Modify AI Agent Configuration, Detection: config-management audit log; integrity check on agent prompt + tool catalog. Mitigation: agent config under version control (git); config changes require change-management approval; integrity attestation on agent startup.
• RAG Credential Harvesting, Detection: KB-content scanning for embedded credentials (CI gate); retrieval-content scanning at runtime. Mitigation: credential-scanning of KB before ingestion; retrieval-output secrets-detection filter.
• Publish Poisoned AI Agent Tool, Detection: tool catalog under change-management; dependency-vulnerability scan; CycloneDX 1.7 ML-BoM line-item review. Mitigation: tool-catalog allow-list; no runtime tool registration; quarterly dependency review.
• Escape to Host, Detection: sandboxed-execution monitoring; resource-usage anomaly detection. Mitigation: tools run in dedicated sandboxed processes; no code-interpreter provisioned; browser tool removed in v1.0.3.

Section 9 - Blast-Radius Calculation

The blast-radius calculation answers the regulator-grade question: how many records, how much money, how much PII can this agent touch on its worst day?

• Records the agent can touch (read):
  • Active Directory user records: ~12,000 (full population: read-attrs scoped per call to requesting-user + manager + direct-reports, but the privileged service account in principle can read any user's attributes)
  • ServiceNow incidents: ~30,000 per quarter active; ~500,000 historical (read-scoped per call to requester/assignee/watcher, but read service account in principle can read any ticket)
  • Microsoft Graph mailbox/calendar metadata: ~12,000 (delegated-permission scoped per call to requesting user only: bounded by OAuth scope)
  • Knowledge-base articles: ~5,000 (employee-accessible only)
  • Per-user memory: ~5,000 active monthly users; ~90-day rolling window
• Records the agent can touch (write):
  • ServiceNow create_ticket: ~30,000 per quarter (rate-limited to 10/min/user; aggregate ~14M/quarter theoretical ceiling, but practical ceiling bounded by user population)
  • ServiceNow update_ticket: ~10,000 per quarter active (agent-originated or agent-assigned)
  • Active Directory password reset: ~12,000 (own-account only per call; max 3/day/user; aggregate ~36,000/day theoretical ceiling, but practical ceiling bounded by user population)
• Money the agent can move:
  • No direct fund movement (no payment-system tools provisioned)
  • Indirect through ServiceNow ticketing: software-request tickets can trigger downstream procurement provisioning. Budget impact bounded by IT-procurement policy ($500 per ticket without secondary approval; $5,000 with manager approval; >$5,000 requires director approval, agent cannot bypass these gates)
  • Worst-case scenario: agent creates 100 fraudulent $500 software-request tickets before detection, $50,000 budget exposure. Mitigation: aggregate per-day ticket-creation alert at 50 tickets/user; SIEM correlation on unusual procurement patterns.
• PII the agent can access:
  • Full HR records for permission resolution: name, employee ID, department, manager, group memberships, work email, work phone (full ~12,000 employees in principle through the read service account)
  • Mailbox metadata (sender, subject, timestamps) via OAuth-on-behalf-of-user: bounded to requesting user only by OAuth scope
  • Calendar free/busy via OAuth-on-behalf-of-user: bounded to requesting user only
  • No salary, performance evaluation, medical, or other special-category data (GDPR Article 9) accessible via provisioned tools
  • No mailbox content (only metadata)
• Worst-case integrated scenario: A successful ASI01 + ASI03 chain (agent goal hijack + identity privilege abuse) on the privileged service account could theoretically affect: ~12,000 password resets at 3/day/user rate-limit (so practical attack ceiling ~36,000 reset attempts/day before circuit breakers fire); confirmation gate requires MFA second factor for each reset, materially constraining mass-reset attacks. Detection time target: <15 minutes via SIEM aggregate-pattern alert.
• Blast-radius vs autonomy-tier check: Privileged actions (password reset, ticket creation) operate at "Confirm" tier (MFA gate, manager-approval gate); read actions operate at "Act" tier. No action operates at "Autonomous" tier in v1.0.3.

Section 10 - Autonomy-Tier Mapping

Per agent action type, the operating autonomy tier (Suggest / Confirm / Act / Autonomous). The tier determines the Article 14 oversight design and the Article 26(4) effectiveness-monitoring metric.

• KB lookup, retrieve ticket context, draft reply-Suggest. Agent produces text; user reads; user accepts/edits before any action.
• Create ServiceNow ticket (standard category, <$500 procurement impact)-Act. Agent creates ticket; user notified; user can cancel within 5 minutes.
• Create ServiceNow access-request ticket (manager approval required)-Confirm. Agent drafts ticket; user reviews and confirms; agent submits for manager approval.
• Password reset-Confirm (MFA second factor required). Agent initiates; MFA second factor by user; agent executes reset.
• Tier 2 escalation-Suggest. Agent recommends escalation; human reviewer accepts/rejects; agent routes if accepted.
• No Autonomous-tier actions in v1.0.3. Future Q3 2026 candidate: routine ticket-status updates after fully-deterministic resolution path (e.g., "password reset successful → close ticket"), gated on Article 14 oversight-design review.

Section 11 - Article 14 Human-Oversight Design

• Oversight measure 1, pre-action review for Confirm-tier actions: Password reset and access-request tickets require user confirmation before agent executes; manager-approval workflow for access requests adds second layer.
• Oversight measure 2, post-action review sample: 5% sample of Act-tier ticket creations reviewed by Tier 2 helpdesk reviewer within 24 hours; pattern-deviation triggers full investigation.
• Oversight measure 3, escalation routing: Confidence-below-threshold escalates to Tier 2 reviewer; out-of-scope queries refused with escalation suggestion.
• Oversight measure 4, emergency stop-the-system control: Kill-switch via IT-Automation team revokes both service accounts within 5 minutes; tested quarterly.
• Oversight measure 5 - Article 26(3) reviewer competence: 4-hour internal training before review duty; refreshed annually; tabletop exercises quarterly.
• Oversight measure 6, Article 26(4) effectiveness monitoring: Per-quarter oversight-effectiveness metrics, sample-review false-negative rate (target <2%); escalation-routing precision (target >95%); MFA-gate bypass attempts (target zero); reported to AI Governance Committee.

Section 12 - Article 73 Agent-Specific Incident-Response Playbook

The general Article 73 incident-response policy (separate lesson) applies; this section documents agent-specific incident classes and runbooks.

• Rogue-action incident, Definition: agent executes an action outside expected scope (e.g., creates tickets in unauthorized category; calls tool with unexpected parameters). Detection: SIEM aggregate-pattern alert; tool-call audit-log review. Initial response: revoke privileged service account; freeze readonly service account write paths; preserve logs. 72-hour Article 73 assessment.
• Tool-abuse incident, Definition: agent's tool calls indicate compromise or misuse (e.g., password-reset attempts on non-requesting-user accounts; rate-limit-violation patterns). Detection: per-tool anomaly detection; SIEM correlation. Initial response: disable affected tool; preserve logs; rotate service-account credentials. 72-hour Article 73 assessment.
• Memory-poisoning incident, Definition: agent memory content shows evidence of tampering (provenance mismatch; integrity-check failure on summary cache). Detection: nightly integrity check; provenance-tag review. Initial response: flush affected memory partitions; restore from authorized-pipeline snapshot; investigate write-path compromise. 72-hour Article 73 assessment.
• Identity-abuse incident, Definition: agent service account used for actions not attributable to legitimate agent runtime. Detection: SIEM agent-runtime-correlation check; service-account credential-rotation history. Initial response: rotate credentials; investigate compromise vector; freeze agent until cleared. 72-hour Article 73 assessment.
• Cross-organization coordination: Anthropic (base-model vendor) notified per procurement contract clause within 24 hours of any incident potentially attributable to base-model behavior; AISIC notified per voluntary-commitment cadence; market-surveillance authority notified per Article 73 timeline.

Cross-Walks - One System Card, Six Framework Windows

The Acme.HelpdeskAgent v1.0 system card serves multiple frameworks simultaneously:

• EU AI Act: Article 9 RMS (per-tool risk surface + ASI01-ASI10 + blast-radius); Article 10 data governance (memory + KB + training-data inheritance); Article 11 + Annex IV §2(a)-(h) technical documentation (system card as evidence backbone); Article 14 human-oversight design (Section 11); Article 15 robustness/cybersecurity (Sections 6, 7, 8); Article 16 provider obligations (Acme as system provider, deployer of base model + provider of agent system); Article 26 deployer obligations (Section 11 + Article 26(3) competence + Article 26(4) effectiveness); Article 27 FRIA reference (if Annex III applicability, not applicable here); Article 50(1) chatbot disclosure (Section 5); Article 72 post-market monitoring (Section 11 effectiveness + Section 12 incident response); Article 73 incident reporting (Section 12).
• ISO/IEC 42001:2023: A.6.1.1 impact assessment; A.6.2 impact criteria; A.6.4 post-deployment monitoring; A.7 data governance (Section 4 memory + Section 3 tool data flows); A.8 information for users (Section 5 consent + Article 50 disclosure); A.10 third-party relationships (Anthropic + Qdrant + ServiceNow + Microsoft).
• NIST AI RMF: Map 1 context (Section 1); Map 2 categorization (Section 2 risk tier); Map 3 capabilities (Sections 3-6); Map 4 third-party (Anthropic + tool vendors); Measure 1 methods (Section 7 + 8 assessment); Measure 2 evaluation (Section 11 effectiveness metrics); Manage 1 prioritization (Section 7 + 9 blast radius); Manage 4 response (Section 12).
• NIST AI 600-1 GenAI Profile: Risk 2 confabulation (Section 6 guardrails); Risk 6 data integrity (Section 4 memory poisoning defenses); Risk 10 information security (Sections 5, 6, 7, 8); Risk 11 value chain (Section 2 + ASI05); Risk 12 harmful bias (inherited from base model; effectiveness metrics include refusal-pattern review).
• OWASP Agentic Top 10: ASI01-ASI10 explicit per-category coverage in Section 7.
• MITRE ATLAS: Agentic techniques in Section 8 with detection + mitigation.

One artifact, six framework windows. The system card is the L2 exemplar of evidence efficiency for agent deployments.

Publication, Retention, and Refresh

• Internal: IT-Automation Engineering, IT Operations, AI Officer team, AI Governance Committee, Security team, full access.
• Employee-facing summary: Sections 1, 2 (model selection only), 3 (tool list at category level), 4 (memory at policy level), 5 (consent), 6 (guardrails at category level), 11 (oversight), 12 (incident playbook at category level), published on internal intranet for transparency.
• Regulator-facing: Full version furnished on request as part of Article 11 + Annex IV §2 evidence; integrated with the Article 27 FRIA where applicable (not applicable for this internal-helpdesk deployment).
• Retention: Per Article 18 (typically 10 years for high-risk; Acme retains all system cards at the same standard); ISO 42001 A.7 documentation retention.
• Refresh cadence: Quarterly review; triggered updates on tool catalog change, memory architecture change, base-model version change (Anthropic minor release), service-account scope change, OWASP/ATLAS technique addition, red-team finding, Article 14 oversight-design change, ASI01-ASI10 exposure-level change.

Six Common Mistakes in Agent System Cards

Mistake 1 - Documenting the Model but Not the Tools

A system card that documents the underlying model and ignores the tool list is half a system card. The tool list is where the agent's risk surface lives: per-tool scope, permissions, rate limits, and audit logging are what regulators and auditors will ask about first. Each tool needs its own row in Section 3.

Mistake 2 - No Memory Hygiene Policy

Persistent memory is a new attack surface (ASI06 Memory Poisoning) and a new privacy surface (cross-user / cross-session leakage). Skipping memory hygiene, provenance tagging at write, cross-user-pattern detection, authorized-pipeline-only writes for shared memory, GDPR Article 15/17 disclosure-and-deletion flows, leaves the agent vulnerable and the system card incomplete.

Mistake 3 - Weak Identity and Consent Boundaries

A single service account doing everything is a privilege-abuse incident waiting to happen. Two-tier service accounts (readonly + privileged), 30-day rotation, SIEM logging, OAuth-on-behalf-of-user for personal data, user-consent flows at session start, and Article 50(1) chatbot disclosure are all baseline. Article 14 oversight requires the human reviewer to know whose identity each action ran under.

Mistake 4 - Skipping OWASP Agentic Top 10 Coverage

OWASP Agentic Top 10 (ASI01-ASI10) is the 2026 standard agentic-risk taxonomy. Skipping per-category coverage in the system card leaves the agent's risk posture undocumented and the regulator asking "which agentic risks did you assess?" Each ASI category needs an applicability + mitigations + residual + acceptance row.

Mistake 5 - No Blast-Radius Calculation

The blast-radius calculation (records readable/writable, money movable, PII accessible) is the single most regulator-grade question about an agent deployment. Skipping it means the regulator and the auditor compute it for you, and they will use worst-case assumptions. Compute it explicitly, document the bounding assumptions, and demonstrate the rate-limit + confirmation-gate + circuit-breaker mitigations that constrain the practical ceiling below the theoretical ceiling.

Mistake 6 - Treating the System Card as Static

Agents change weekly: tool catalog updates, memory architecture refinement, base-model minor releases, OWASP/ATLAS technique additions, red-team findings. Quarterly refresh + triggered updates on tool catalog change, memory architecture change, base-model version change, service-account scope change, OWASP/ATLAS technique addition, red-team finding, Article 14 oversight-design change, ASI01-ASI10 exposure-level change. A static system card from deployment time is stale within a quarter.

Key Takeaways

• An agent is a system of (model + tools + memory + identity + guardrails), not a model with a UI. The system card documents the integrated system as the unit of disclosure; the model card alone is insufficient.
• The 10+ section system card structure covers agent identity, underlying model, tool list, memory architecture, identity/consent, guardrails, OWASP Agentic Top 10 exposure, MITRE ATLAS agentic techniques, blast-radius, autonomy-tier mapping, Article 14 oversight design, Article 73 incident-response playbook.
• The tool list is the heart of the system card. Each tool documented with name, purpose, scope, permissions, rate limits, audit logging, and tool-specific guardrails, that is where the agent's risk surface lives.
• Memory is a new attack and privacy surface. Persistent memory needs provenance tagging at write, cross-user-pattern detection, authorized-pipeline-only writes for shared memory, and GDPR Article 15/17 disclosure-and-deletion flows.
• Identity is layered (agent service accounts + OAuth-on-behalf-of-user) and consent is explicit. Two-tier service accounts (readonly + privileged), 30-day rotation, SIEM logging, Article 50(1) chatbot disclosure, Article 26(3) reviewer competence.
• OWASP Agentic Top 10 (ASI01-ASI10) per-category assessment is the 2026 standard agentic-risk taxonomy. Each ASI category needs applicability + mitigations + residual + acceptance.
• The blast-radius calculation is the regulator-grade question. Records readable/writable, money movable, PII accessible: explicit numbers, bounding assumptions, and rate-limit/confirmation-gate/circuit-breaker mitigations.
• Autonomy-tier mapping (Suggest / Confirm / Act / Autonomous) per agent action determines Article 14 oversight design and Article 26(4) effectiveness metrics.
• One artifact, six framework windows. EU AI Act + ISO 42001 + NIST AI RMF + NIST AI 600-1 + OWASP Agentic + MITRE ATLAS, the system card is the L2 exemplar of cross-walk evidence efficiency for agents.
• The system card is a living document. Quarterly refresh + triggered updates on tool catalog change, memory architecture change, base-model version change, service-account scope change, OWASP/ATLAS additions, red-team findings, Article 14 oversight-design change, ASI exposure-level change.