# Securing Astra CMS for Humans and AI Agents: An Identity-First Approach to IAM "Hackers don't break in, they log in." That one line from a recent identity-security briefing explains why a CMS that is about to host AI agents needs an identity plan before it needs anything else. The same briefing cites two numbers worth remembering: roughly 80% of cyber incidents involve compromised identities, and a breach that starts with stolen credentials takes about 243 days on average to identify and contain (sources named in the slides: Rubrik and the IBM Cost of a Data Breach Report 2026). Now add AI agents to the picture. Another talk in the same series quotes Forrester (2025): 89% of agents run on static or shared credentials, and none of the legacy IAM systems were designed for them. This post takes ideas from those two talks and maps them onto [Astra CMS](https://github.com/ZeroHostCMS/astra-cms), an open-source (MIT), metadata-driven, plugin-first platform built on Java 25, Quarkus and PostgreSQL that exposes both a REST API and an MCP server. I will separate what the repository says exists today from what I recommend you add. ## Why a CMS has the "non-human identity" problem too A human identity is simple: an employee, partner or customer acting on their own behalf, with long-lived credentials and role-based access that is stable for months. Non-human identities (NHI) are different. They are service accounts, API keys and AI agents. They act on someone else's behalf, so every action must be tied to that person's intent. Their credentials must be short-lived and rotated automatically, and their access should be task-based and change per session. The talk puts the ratio at 45 to 90 non-human identities for every human one. Astra CMS makes this concrete. Desk, mobile and AI-agent clients all call one server, and that server publishes DocTypes and extension points as MCP tools. An agent is just another caller. The question is whose authority it carries. ## Three gaps where people and machines meet The talks name three recurring gaps. Each one has a direct counterpart in an Astra deployment. **1\. Accountability.** Agents act without being tied to a human identity, so breach forensics become guesswork. In Astra, the repository states that agents work under the same permissions and audit as users, and MCP tools are scoped by role and tenant. Keep it that way: never give an agent a shared service login. **2\. Static credentials.** A leaked long-lived key keeps working until someone rotates it. The repo supports field-level encryption (`encrypt: field`) and a `KeyProvider` extension point for KMS, HSM and bring-your-own-key. It does not describe API key issuance or rotation, so treat that as your job. **3\. Over-privilege.** An agent with broad standing permissions has a large blast radius and can become a "confused deputy": steered into doing what its user is not allowed to do. Astra's per-DocType permissions with row-level conditions are the right foundation. The project demo shows a payment voucher's maker being blocked from approving it with a 403. ## What Astra CMS already gives you From the repository description, the identity and security building blocks are: - Sign-in through Keycloak with PKCE, and roles mapped to Keycloak groups. - SAML SSO with a signed identity provider, where IdP groups map to tenant roles. - SCIM 2.0 user provisioning per tenant, which is the automation behind joiner-mover-leaver. - Permissions declared per DocType, including row-level conditions. - Tenancy enforced with PostgreSQL row-level security. The kernel refuses to start as a superuser, and the application role is NOSUPERUSER and NOBYPASSRLS. - Fail-closed behavior: a cross-tenant query returns 0 rows, and an unclear tenant gets a 403 or 400. - A WebAssembly sandbox for plugins that limits memory, enforces deadlines and blocks host access that was not granted. AI-generated code defaults to the sandbox and records `provenance.generator`. - An append-only ledger, version history on every save, and an `AuditSink` extension point for SIEM exporters. - Compliance metadata per DocType: classification, retention, legal basis, residency and PII masking. That is a strong human-IAM and data-isolation story. The gap, as in most platforms, is on the agent side. ## The reference pattern: an agent acting on a user's behalf One of the slides walks through a clean pattern that I think fits Astra well. Two users, Alice (read only) and Bob (read and write), ask the same agent the same thing: "Can you add a Flat White for $4?" Alice is refused, Bob succeeds, because every credential is derived from the user's own group. The steps, translated to Astra: 1. The user signs in to the identity provider (Keycloak with PKCE). 2. The user's token is exchanged for an on-behalf-of token that names both the user and the agent. 3. The MCP server validates that token and its permission scope. 4. If the tool needs a downstream secret, a secrets broker issues a short-lived, just-in-time credential only after the identity check passes. 5. Astra checks the role and tenant on every call, and returns 403 or 0 rows if denied. 6. The credential expires after a short time-to-live, and the audit log links every action person to agent to resource. ![Diagram: an AI agent acting on a user's behalf in Astra CMS](https://cdn.hashnode.com/uploads/covers/68241e9f3be1095ac4d08cae/44ef4f13-944b-4266-a915-cbf71e180403.png align="center") The talks implement this with IBM Verify and HashiCorp Vault. You do not have to use those products. Keycloak plays the identity-provider role Astra already ships with, and the `KeyProvider` SPI is the natural seam for plugging in Vault, a cloud KMS or an HSM. The pattern matters more than the vendor. ## Five requirements to hold your design against The keynote distills enterprise agent security into five requirements. Here is how I would read them for Astra: 1. **Register every agent.** Each agent gets a unique, cryptographically verifiable identity. No shared keys. 2. **Remove standing privilege.** Access is just in time and just enough, and expires by itself. 3. **Link actions to intent.** Record who delegated what, for what purpose, and be able to trace and revoke it immediately. 4. **Enforce centrally.** Validate every API call against policy, and never execute outside the allowed scope. 5. **Provide evidence.** Log actions and decisions to an audit trail that can prove what happened. The keynote also warns about "Shadow AI": agents with no identity, no runtime controls and no audit trail. In a CMS, that looks like an editor wiring a copilot to the MCP endpoint with a personal admin token. Make that impossible by policy, not by trust. ## A maturity ladder for your Astra deployment The Identity Fabric talk describes three levels. Mapped onto Astra: ![Identity maturity ladder for an Astra CMS deployment](https://cdn.hashnode.com/uploads/covers/68241e9f3be1095ac4d08cae/7780aab3-4f89-4b31-be16-d94453c3da9e.png align="center") - **Level 1, identity silos:** local accounts, shared API keys in config, access granted by message or ticket. Fine for a laptop demo, wrong for production. - **Level 2, humans centralized:** Keycloak with MFA, SAML SSO, SCIM joiner-mover-leaver, and DocType permissions with row-level rules. Most teams can reach this level quickly because Astra ships the pieces. - **Level 3, humans and agents connected:** every agent registered and tied to a named user, short-lived role-scoped secrets, no standing privilege, and one audit trail exported through `AuditSink` to your SIEM. The talk's advice is "connect what you have, don't replace it", and "clean human entitlements today, safe AI agents tomorrow". I agree: an agent can never be safer than the user permissions it inherits. ## A practical checklist - Enforce MFA or passkeys at the identity provider, and use SSO for every human. - Turn on SCIM so leavers lose access automatically, then run periodic access reviews. - Define least-privilege roles per DocType before you expose any DocType over MCP. - Issue each agent its own identity and bind every call to the delegating user. - Put secrets behind a `KeyProvider` (KMS, HSM or Vault), keep TTLs short and rotate automatically. - Keep AI-generated plugins in the Wasm sandbox and review `provenance.generator` before promoting them. - Ship audit events to your SIEM and test that you can answer "who had access to what, and when" in minutes, not weeks. - Test denial paths: a read-only user asking an agent to write must fail, exactly like Alice in the demo. ## Going deeper: governing AI itself Identity is the foundation, but the keynote is clear that AI security goes further. Five things are commonly missing: managing data-leak risk, defending against prompt injection, authorizing each AI agent, keeping traceable logs, and having an emergency stop mechanism. The keynote's proposed response is organizational as much as technical: - Assign a single accountable owner for AI security. - Issue a governance framework. NIST AI RMF is a good reference point. - Run attack testing (red team) before anything goes into production. For Astra, this means a named owner for every agent-enabled DocType, a documented policy for which tools an agent may call, a kill switch that can revoke an agent identity and its credentials at once, and prompt-injection tests against your MCP tools before release. The keynote's own example shows why: an untrusted note in a customer profile tells the agent to skip approval and send money to an attacker's account. Least privilege limits the damage, and red-team testing finds the hole first. ## Honest status note The Astra CMS repository separates what runs today (the thin slice, Keycloak sign-in, the MCP server, the Wasm sandbox and the k3d deployment) from the target architecture, and says some target code samples do not compile yet. Several items above, notably agent registration, on-behalf-of token exchange and dynamic credential issuance, are recommendations built on its extension points, not features I verified as shipped. Check `SECURITY.md` and the `astra-iam` and `astra-spi` modules before relying on any of them. ## Sources and credits - Astra CMS repository: - "Build a Unified Identity Fabric with a Strong IAM Platform" (Amigo, IBM Platinum Partner). - "Building Trust, Identity and Security for the Agentic AI Era" (Ngo Thanh Hien, CTO IBM Vietnam). - Statistics quoted as presented in those slides: Rubrik, IBM Cost of a Data Breach Report 2026, Gartner 2025, Forrester 2025.