Last Updated on May 13, 2026 by Arnav Sharma
In 2025, prompt injection appeared in 73% of production AI deployments. Not in labs. Not in red team exercises. In production — in systems your peers built and shipped.
That number isn’t a reason to pause AI adoption. It’s a reason to build the security architecture correctly from the start. The problem isn’t that agentic AI is inherently insecure. The problem is that most organizations are securing it with the wrong model — treating autonomous AI agents like smarter chatbots, then wondering why their threat surface looks nothing like what their existing controls cover.
Securing agentic AI requires a different threat model, different controls, and a different architecture philosophy. This guide gives you all three: a clear breakdown of the attack vectors that matter, six architecture principles that hold up at scale, a mapping to OWASP/CISA/NIST frameworks, and a pre-deployment checklist you can use this quarter.
Intended audience: Security architects, CISOs, and DevSecOps leads deploying or evaluating agentic AI systems in enterprise environments.
Why Agentic AI Security Is Different (And Why That Gap Is Dangerous)
Most security teams approach AI security as an extension of application security. That works for large language models operating in isolation. It breaks down the moment your LLM starts taking actions.
The operational difference is fundamental.
The Traditional AI Security Model Doesn’t Apply Here
A traditional AI model has a predictable security boundary: input goes in, output comes out, a human decides what to do with it. The threat surface is narrow — prompt injection risks, output filtering, data privacy in the training pipeline.
An agentic AI system operates in a completely different loop:
Goal → Planning Module
├── Tool calls (APIs, browsers, databases, code execution)
├── Memory (short-term context + long-term storage)
├── Self-evaluation
└── Next action → Loop repeats autonomously
Every node in that loop is a potential injection point, a privilege escalation opportunity, or an unmonitored exfiltration path. The agent isn’t responding to a prompt — it’s pursuing a goal, making decisions, accumulating context, and executing actions that have real downstream consequences.
The security implications compound: a compromised agent doesn’t just return bad output. It acts. It calls APIs, modifies data, sends communications, and delegates tasks to other agents — often before any human has reviewed what it’s doing.
What “Autonomy” Actually Means for Your Attack Surface
Three properties of agentic AI systems create attack surfaces that traditional security architectures weren’t designed to handle:
1. Persistent memory across sessions. Agents can maintain long-term memory stores. That memory is a target. A single well-placed injection into an agent’s memory can compromise interactions for months — and propagate silently, because the agent is operating normally from its own perspective.
2. Tool chaining across systems. An AI agent executing a workflow might call your CRM API, query a database, send an email, execute code, and write to cloud storage — all in a single session. Each tool call is a lateral movement opportunity. The agent’s authorized access becomes the attacker’s foothold.
3. Multi-agent orchestration. Enterprise agentic AI systems don’t run as single agents. They run as orchestration networks — a coordinator agent delegating tasks to specialized sub-agents, each with its own permissions and tool access. Trust chains between agents are a novel and largely unsolved attack surface. A compromised sub-agent can poison upstream decisions. A malicious orchestrator can abuse every agent it coordinates.
And then there’s MCP.
The Model Context Protocol — the emerging standard for connecting AI agents to external tools and data sources — introduces a software supply chain risk vector that most security teams haven’t begun to address. A malicious or compromised MCP server can inject hidden instructions at runtime, impersonate a trusted tool provider, or silently redirect an agent’s actions. This is the agentic equivalent of a compromised npm package, except it executes with your agent’s full permissions.
The bottom line: your existing security frameworks were built for systems that wait for instructions. Agentic AI systems initiate their own activities based on goals — and that changes everything.
The Agentic AI Threat Model: 6 Attack Vectors That Matter in 2026
Before you can design controls, you need an accurate threat model. The six vectors below represent the highest-impact, most actively exploited risks in deployed agentic AI systems today — mapped to OWASP’s Agentic Security Initiative Top 10 (ASI-10) and grounded in confirmed incident data.
1. Prompt Injection (Direct and Indirect)
Prompt injection is the defining vulnerability of agentic AI — and it’s more dangerous in autonomous systems than in chatbots, because the agent acts on what it’s told.
Direct injection arrives through user input: a maliciously crafted prompt that overrides the agent’s system instructions and redirects its behavior. In a human-in-the-loop system, the damage is limited to what the user sees. In an autonomous agent, the damage is whatever the agent is authorized to do.
Indirect injection is the harder problem. The malicious payload isn’t in the user’s prompt — it’s embedded in content the agent retrieves and processes: a web page, a PDF, an email, an API response. The agent reads it, interprets it as instruction, and acts on it. The user may never know it happened.
This isn’t theoretical. In May 2026, Microsoft’s Security Research team disclosed CVE-2026-26030, a remote code execution vulnerability in a production AI agent framework triggered through a prompt injection that escalated into a Python eval() execution sink. The attack surface: a hotel-finder agent processing externally retrieved web content. The payload: a crafted prompt buried in a third-party listing page.
OWASP ASI-10 mapping: ASI-01 (Goal Hijacking), ASI-02 (Prompt Injection)
2. Privilege Escalation via Tool Misuse
This is the confused deputy problem — reborn for the AI era.
Agents are granted broad permissions to function effectively: read-write access to CRMs, code repositories, cloud infrastructure, financial systems, and communication platforms. That access is necessary for the agent to do its job. It’s also exactly what an attacker wants.
The attack pattern is precise: craft an input that tricks the agent into using its own legitimately authorized tools in unauthorized ways. The attacker never touches your infrastructure directly. The agent does it for them — with credentials that look completely normal in your logs.
Tool misuse and privilege escalation represent the most common confirmed attack class in agentic AI deployments, with 520 incidents documented in 2026 threat intelligence reporting. The underlying cause in nearly every case: over-permissioned agents with no task-scoped credential boundaries.
OWASP ASI-10 mapping: ASI-03 (Excessive Agency)
3. Memory Poisoning
Long-term memory is one of the most powerful features of advanced agentic AI systems. It’s also a persistent, hard-to-detect attack surface.
An attacker who successfully plants a malicious instruction in an agent’s memory store doesn’t need to maintain access. The agent carries the payload forward — into every future session, for every future user, potentially across months of operation. Standard incident response assumptions break down: you’re not looking for an active intrusion. You’re investigating a compromise that may have started before the agent was ever deployed in its current configuration.
Detection is difficult because the agent behaves normally — it’s following its memory, as designed. The deviation is in what that memory contains.
OWASP ASI-10 mapping: ASI-04 (Memory Poisoning)
4. Goal Hijacking and Behavioral Misalignment
OWASP rates this the highest-severity risk in the ASI-10. It’s also the least visible.
Goal hijacking occurs when an attacker manipulates the agent’s core mission — not its tool use, not its output, but its objective. The agent continues to operate normally from an observability standpoint: it’s calling the right tools, logging the right events, producing plausible outputs. It’s just serving a different goal than the one you gave it.
Behavioral misalignment is the broader failure mode: agents that drift from their intended purpose due to ambiguous instructions, conflicting goals, or accumulated context corruption. The drift may be attacker-driven or emergent. Either way, the security implications are equivalent — you have an autonomous system with enterprise access operating outside its defined parameters.
OWASP ASI-10 mapping: ASI-01 (Goal Hijacking), ASI-07 (Misaligned Behaviors)
5. Multi-Agent Cascading Failures
Single-agent security is a solved problem compared to what happens in orchestrated multi-agent systems.
In a multi-agent architecture, agents communicate with each other — passing context, delegating subtasks, sharing memory. There is no established standard for how agents authenticate each other or validate instructions passed between them. In most current frameworks, inter-agent trust is implicit: if a message arrives from a peer agent, it’s treated as trusted.
That assumption is an attack vector. A compromised sub-agent can poison the context passed to an orchestrator. A malicious orchestrator can abuse every agent it coordinates. A single injection at one node can cascade through an entire workflow before any human sees output.
Circuit breakers — hard stops that halt agent workflows when anomalous behavior is detected at any node — are the primary architectural mitigation. They’re also largely absent from default framework configurations.
OWASP ASI-10 mapping: ASI-09 (Cascading Agent Failures)
6. Agentic Supply Chain Attacks
Unlike traditional application dependencies, agentic AI systems compose capabilities dynamically at runtime. An agent can load a new tool, connect to an MCP server, or invoke a plugin it has never used before — based on a task description, not a pre-approved list.
This makes supply chain security dramatically harder. You can’t audit what you haven’t yet loaded. A malicious MCP server impersonating a legitimate tool provider can inject hidden instructions into the agent’s runtime context. A compromised tool definition can include example code pointing to attacker-controlled endpoints, or schema parameters that silently enable privilege escalation.
The agentic supply chain attack is the npm left-pad problem with your agent’s full enterprise permissions attached.
OWASP ASI-10 mapping: ASI-08 (Agentic Supply Chain Vulnerabilities)
Attack Vector Summary
| Attack Vector | Severity | OWASP ASI-10 | Primary Detection Signal |
|---|---|---|---|
| Prompt Injection (Indirect) | Critical | ASI-01, ASI-02 | Unexpected tool calls following external data retrieval |
| Privilege Escalation / Tool Misuse | Critical | ASI-03 | Anomalous API calls using valid credentials |
| Memory Poisoning | High | ASI-04 | Behavioral drift across sessions; unexpected memory entries |
| Goal Hijacking | Critical | ASI-01, ASI-07 | Plausible outputs inconsistent with original intent |
| Cascading Multi-Agent Failures | High | ASI-09 | Downstream agent behavior diverging from orchestrator intent |
| Supply Chain (MCP/Plugin) | High | ASI-08 | New runtime tool sources not in approved inventory |
Securing Agentic AI: A Practical Architecture Framework
Knowing the threat model is necessary. Having a framework that maps to it is what actually closes the gap.
The six principles below are architecture-level commitments — design decisions that need to be made before you deploy, not controls bolted on afterward. They’re framework-agnostic (LangChain, AutoGen, CrewAI, Microsoft Copilot Studio, Salesforce Agentforce — the principles apply regardless) and they map directly to OWASP ASI-10, CISA’s May 2026 guidance, and NIST AI RMF.
Principle 1 — Treat Every Agent as a First-Class Identity
This is where most enterprise deployments fail first.
Non-human identities already outnumber human identities roughly 50:1 in the average enterprise. Agentic AI accelerates that ratio — and most IAM architectures weren’t designed for it. Agents are frequently deployed with shared service accounts, static long-lived credentials, and permissions inherited from a human user who set them up manually.
That’s not an identity model. That’s a liability.
Every AI agent needs its own identity: independently provisioned, independently auditable, and independently revocable. That means:
- Unique credentials per agent — never shared service accounts across agent instances or workflows
- Just-in-time provisioning — credentials issued at task start, revoked at task completion, not persisted between sessions
- Scoped OAuth with minimal claims — Zero Trust OAuth patterns, not broad delegated permissions inherited from a human user
- Full audit trail — every action the agent takes must be attributable to that specific agent identity, not a shared account
If your SIEM can’t tell you which specific agent instance made which API call at which time, you don’t have agent identity. You have agent ambiguity — and ambiguity is what attackers exploit.
Principle 2 — Enforce Least Privilege at Every Tool Call
Least privilege isn’t a new concept. Applying it correctly to agentic AI systems requires rethinking how and whenpermissions are evaluated.
The failure mode is common: an agent is granted broad permissions at deployment time because the team isn’t sure exactly what it will need. Those permissions persist. The agent accumulates entitlements through normal operation. Six months later, you have an agent with read-write access to twelve systems it currently uses one of — and your access control review cycle hasn’t caught it because the agent’s activity looks normal in aggregate.
OWASP’s guidance on excessive agency (ASI-03) is specific: scope permissions to individual tasks, use short-lived credentials, and revoke access when a task completes. This requires moving from agent-level access control to task-level access control — a meaningful architectural shift, but the correct one.
In practice:
- Scoped API keys per workflow step, not per agent globally
- Agents that need to read a database should not have write access
- Agents that send customer emails should not be able to email arbitrary addresses
- Credentials for one API should not be bundled with credentials for ten
- Transitive privilege inheritance across agent chains must be explicitly blocked — a sub-agent should never automatically inherit its orchestrator’s permissions
39% of organizations currently report over-permissioned agents in production. That number should concern you — because every over-permissioned agent is a confused deputy waiting to be exploited.
Principle 3 — Design Human Approval Gates Deliberately
“Add human oversight” is advice. Knowing where to add it is security architecture.
The goal isn’t to require human approval for every agent action — that eliminates the operational value of autonomy entirely. The goal is to identify the specific action categories where the cost of an incorrect autonomous decision exceeds the cost of the interrupt-and-confirm latency.
A working decision framework for gate placement:
| Action Category | Risk Level | Recommended Gate |
|---|---|---|
| Financial transactions above threshold | Critical | Explicit human approval |
| Code deployment to production | Critical | Explicit human approval |
| External communications (customer-facing) | High | Review queue or confidence threshold |
| Data deletion or bulk modification | Critical | Explicit human approval |
| New credential issuance or permission grant | Critical | Explicit human approval |
| Internal read-only data queries | Low | Audit log only |
| Drafting content for human review | Low | Audit log only |
Implementing this in practice means building interrupt-and-confirm patterns into your agent workflows — not as afterthoughts, but as first-class architectural components. LangChain’s human-in-the-loop callbacks, AutoGen’s human proxy agent pattern, and CrewAI’s task approval hooks all provide mechanisms for this. The security team needs to own the policy that governs when those mechanisms activate, not leave it to individual development teams to decide.
Principle 4 — Build Agent-Native Observability
Your existing SIEM rules will not catch anomalous agent behavior. This is not a criticism of your SIEM — it’s an architectural reality.
Standard detection rules look for patterns in human-speed activity: unusual login times, lateral movement across systems, bulk data access. An agent can execute hundreds of API calls, query multiple databases, and exfiltrate sensitive information in the time it takes a human analyst to review a single alert. The volume, speed, and cross-system nature of agent activity looks like normal automation noise to most existing detection stacks.
Agent-native observability requires logging and monitoring at a different layer:
- Goal state logging — what objective was the agent pursuing at each decision point?
- Tool-use pattern logging — which tools were called, in what sequence, with what parameters?
- Decision pathway logging — what reasoning led from input to action?
- Anomaly baselines per agent — not per user, not per service account, per agent workflow
Custom detection rules to build immediately:
- Unusual data volume in a single agent session vs. established baseline
- Tool calls to destinations outside the agent’s approved scope
- Off-hours activity on agents that operate within defined windows
- Permission scope changes or new credential issuance during active sessions
- Inter-agent communication patterns inconsistent with defined workflow topology
Microsoft’s open-source Agent Governance Toolkit (released April 2026) is the most complete reference implementation available today — addressing all 10 OWASP agentic risks with deterministic, sub-millisecond policy enforcement integrated directly into LangChain, CrewAI, AutoGen, and Microsoft Agent Framework through native extension points. It’s worth reviewing as a baseline architecture reference regardless of which framework you’re deploying on.
Principle 5 — Harden the Input/Output Pipeline
Every data source your agent ingests is a potential injection vector. Treat all of them as untrusted — including data sources your organization controls — because the content of those sources may have been manipulated upstream.
Input hardening:
- Validate and sanitize all external content before it reaches the agent’s context window: web pages, email content, document attachments, API responses, database query results
- Apply content filtering tuned for instruction-like patterns — not just malware signatures or known-bad strings, but semantic patterns that indicate an attempt to redirect agent behavior
- Treat indirect prompt injection as a first-class threat category in your security controls, not a theoretical edge case
Output hardening:
- Filter agent outputs for credential patterns, PII, and sensitive data before they reach downstream systems or external destinations
- Implement output schema validation — if an agent is supposed to produce a structured JSON payload, any deviation from schema is an anomaly worth investigating
- Log all agent outputs with full context: what input produced this output, via what tool calls, in service of what goal
The attacker’s path through your agent’s I/O pipeline is often the path of least resistance. Closing it requires treating the agent’s context window as a security boundary — not just a technical component.
Principle 6 — Secure the Orchestration Layer and Supply Chain
The orchestration layer — the infrastructure that coordinates multi-agent workflows, routes tasks between agents, and manages shared context — is the highest-value target in a mature agentic AI deployment. Compromise the orchestration layer and you don’t compromise one agent. You compromise every agent it coordinates.
Orchestration security:
- Validate and sanitize all inter-agent communications — never assume a message from a peer agent is trustworthy without verification
- Implement explicit trust boundaries between agent tiers: orchestrator agents, sub-agents, and tool-executing agents should operate under different permission models
- Deploy circuit breakers at orchestration layer: define the conditions under which the system halts a workflow and escalates to human review rather than continuing autonomously
- Block transitive privilege inheritance: a sub-agent receiving a delegated task should receive only the permissions required for that task, not the full permission set of the delegating agent
Supply chain security:
- Maintain an approved inventory of MCP servers, plugins, and tool definitions — and enforce it at runtime, not just at deployment
- Pin tool and plugin versions; monitor for supply chain tampering between deployments
- Audit tool definitions for hidden prompts, overly permissive schemas, and example code referencing external endpoints
- Treat any dynamically loaded tool source with the same scrutiny you’d apply to a third-party dependency in a production codebase — because that’s exactly what it is
Framework Alignment: OWASP, CISA, NIST, and Zero Trust Mapped
The six principles above don’t exist in a vacuum. They map directly to the major frameworks your organization is likely already using for AI risk management and cybersecurity governance.
| Architecture Principle | OWASP ASI-10 | CISA Guidance (May 2026) | NIST AI RMF | Zero Trust Pillar |
|---|---|---|---|---|
| Agent Identity (P1) | ASI-06: Identity Abuse | Strong authentication, Secure by Design | GOVERN 1.2 | Identity |
| Least Privilege (P2) | ASI-03: Excessive Agency | Privilege creep mitigation | MANAGE 2.4 | Least Privilege |
| Human Approval Gates (P3) | ASI-01: Goal Hijacking | Human oversight requirements | GOVERN 6.1 | — |
| Agent-Native Observability (P4) | ASI-09: Cascading Failures | Obscure event records mitigation | MEASURE 2.5 | Visibility |
| Input/Output Hardening (P5) | ASI-02: Prompt Injection | Deception indicator detection | MANAGE 2.2 | Data |
| Orchestration & Supply Chain (P6) | ASI-08: Supply Chain | Dependency vetting | GOVERN 1.7 | Applications |
Where the frameworks diverge — and where the gaps are:
CISA’s May 2026 guidance covers design and deployment phases well but is light on runtime controls and agent-to-agent trust. It’s a strong compliance anchor, weaker as an operational security guide.
OWASP ASI-10 is the most operationally specific framework available today. Its weakness: it tells you what the risks are with considerably more precision than it tells you how to mitigate them at the architecture level.
NIST AI RMF provides governance structure that integrates well with existing enterprise risk programs, but its AI-specific controls lag behind agentic deployment velocity. Map to it for organizational alignment — don’t rely on it alone for technical controls.
Zero Trust is the most directly applicable existing framework, particularly the identity and least-privilege pillars. “Never trust, always verify” translates cleanly to agent identity and inter-agent communication — but Zero Trust was designed for human and device identities, not autonomous agents that dynamically acquire and relinquish permissions mid-workflow. Adaptation is required, not just application.
Practical takeaway: use OWASP ASI-10 as your technical threat reference, CISA and NIST for governance and compliance anchoring, and Zero Trust as your access control philosophy. None of them alone is sufficient. Together, they cover the full agentic security architecture.
Pre-Deployment Security Checklist for Agentic AI Systems
Use this before any agentic AI system goes to production. Each item maps to the six architecture principles above.
Architecture and Identity
- [ ] Every agent has a unique, independently provisioned identity — no shared service accounts across instances
- [ ] Credentials are short-lived: issued at task start, revoked at task completion
- [ ] OAuth scopes are minimized to the specific claims required per workflow step
- [ ] All MCP servers and external tool sources are in an approved, version-pinned inventory
Access Control and Permissions
- [ ] Permissions are scoped at the task level, not the agent level
- [ ] Transitive privilege inheritance across agent chains is explicitly blocked
- [ ] Over-permissioned agents from existing deployments have been audited and remediated
- [ ] A privilege escalation re-authorization flow is in place for elevated access actions
Human Oversight and Guardrails
- [ ] High-risk action categories are defined (financial, code deployment, data deletion, external comms, credential issuance)
- [ ] Interrupt-and-confirm patterns are implemented for each high-risk category
- [ ] Human approval gate policy is owned by security — not delegated to development teams
- [ ] Circuit breakers are configured at the orchestration layer with defined escalation paths
Input/Output Hardening
- [ ] All external data sources treated as untrusted: web, email, docs, API responses
- [ ] Content filtering for instruction-like patterns applied at every ingestion point
- [ ] Agent outputs filtered for credentials, PII, and sensitive data before reaching downstream systems
- [ ] Output schema validation in place with anomaly alerting on deviation
Observability and Detection
- [ ] Goal state, tool-use sequence, and decision pathway logging enabled per agent
- [ ] Per-agent behavioral baselines established and loaded into detection tooling
- [ ] Custom SIEM/SOAR rules active for: anomalous data volume, unexpected API destinations, off-hours activity, scope changes
- [ ] Incident response playbooks cover agent-specific scenarios (memory poisoning, goal hijacking, cascading failure)
Supply Chain and Orchestration
- [ ] Inter-agent communications validated and sanitized — no implicit trust between agent tiers
- [ ] Tool and plugin definitions audited for hidden prompts, permissive schemas, external endpoint references
- [ ] Process in place to detect supply chain compromise between deployments
- [ ] Red team exercises targeting prompt injection and tool misuse scheduled before go-live
Frequently Asked Questions
What is the biggest security risk in agentic AI systems?
Goal hijacking — ranked first in OWASP’s ASI-10 — is the highest-severity risk because it’s the least visible. An agent that has been hijacked continues to operate normally from a surface-level observability standpoint. It calls the right tools, logs the expected events, and produces plausible outputs — while serving an attacker’s objective instead of yours. Prompt injection is the most prevalent risk (73% of production deployments in 2025), but goal hijacking carries the highest potential blast radius in an enterprise environment.
How is prompt injection in agentic AI different from traditional prompt injection?
In a traditional LLM deployment, prompt injection produces bad output. In an agentic AI system, prompt injection produces bad actions — API calls, data modifications, external communications, code execution. The consequence isn’t a misleading response that a human can discard. It’s an autonomous action that may be irreversible before anyone reviews it. Indirect injection — where the payload arrives through content the agent retrieves rather than through user input — bypasses input controls applied at the user interface layer entirely.
Do existing compliance frameworks (SOC 2, ISO 27001) cover agentic AI?
Not adequately. SOC 2 and ISO 27001 were designed for human-operated systems with predictable access patterns. They don’t have native controls for agent identity lifecycle management, task-scoped permissions, or autonomous decision audit trails. NIST AI RMF and OWASP ASI-10 are better references for agentic-specific controls — and regulators are catching up: the EU AI Act’s high-risk obligations take effect in August 2026, and the Colorado AI Act becomes enforceable in June 2026. Mapping your agentic security posture to those requirements now is worth the investment.
What’s the difference between agentic AI security and LLM security?
LLM security focuses on the model: prompt injection, data privacy in inference, output filtering, training data integrity. Agentic AI security focuses on what happens when the model is given the ability to act: identity management, access control, behavioral monitoring, supply chain integrity, multi-agent trust. LLM security is necessary but not sufficient. Every agentic AI security program requires LLM security as a foundation — and then extends significantly beyond it.
Where should an organization start if they’re in early agentic AI deployment?
Start with the checklist above, applied to your first production deployment before it goes live. The highest-leverage early investments are agent identity (Principle 1) and human approval gates (Principle 3) — they address the widest range of threat vectors with the least architectural complexity. Observability comes next: you can’t defend what you can’t see. Least privilege and supply chain hardening require more organizational maturity but should be on your roadmap before you scale beyond a single agent workflow.
Build the Security Architecture Before You Need It
Agentic AI adoption is accelerating faster than enterprise security programs are adapting. The organizations that get ahead of this aren’t the ones with the most tools — they’re the ones that correctly identified the threat model early, made architecture-level commitments before deployment, and built observability into the system rather than onto it.
The framework in this guide isn’t speculative. Every principle maps to confirmed attack patterns, documented incidents, and current guidance from OWASP, CISA, and NIST. The checklist is deployable this quarter. The threat model reflects what’s happening in production environments right now.
Agentic AI systems initiate their own activities, take actions with real consequences, and operate at speeds that outpace traditional human oversight models. Your security architecture needs to be designed for that reality — not retrofitted to it after your first incident.
Start with the checklist. Align to OWASP ASI-10. Build toward the full framework. And revisit your agentic security posture every quarter — this threat landscape is moving faster than any annual review cycle can track.
I help organisations secure their cloud infrastructure and stay ahead of evolving cyber threats. Microsoft MVP and Certified Trainer, author of Mastering Azure Security, and founder of arnav.au — a platform for practical Cloud, Cybersecurity, DevOps and AI content.