ShrikeSecurity & Compliance
Shrike enforces your policy on every AI agent action before it runs, and the record it produces is what your auditor reads. Mapped to NIST CSF 2.0 through the draft Cyber AI Profile (IR 8596): a mapping, not a certification.
Executive Summary
NIST IR 8596, the Cybersecurity Framework Profile for Artificial Intelligence, is a preliminary draft published in December 2025. Its comment period closed in January 2026, and NIST has said an initial public draft follows. It applies CSF 2.0 to AI through three focus areas: securing AI systems, thwarting AI-enabled attacks, and conducting AI-enabled defense.
Shrike sits in the first two. It secures the agent's actions, and it is the runtime control an AI-enabled attack on an agent has to get past. The mapping below names the CSF 2.0 subcategory, quotes it, and says what Shrike does for it. Where a subcategory is yours to satisfy and Shrike only produces the evidence, it says that too.
Nothing on this page is a certification. Shrike produces records; your auditor issues opinions.
Focus Area Alignment
Securing AI systems
Focus area one: the agent's actions stay inside your policy.
- Pre-execution checkEvery tool call, command, query, file write and agent message evaluated before it runs
- Declared scope, least privilegeWhat the agent is for and what it holds; it cannot widen its own scope
- Data in usePersonal data redacted rather than blocked; no prompt content in service logs; TLS in transit; retention per the Privacy Policy
Thwarting AI-enabled attacks
Focus area two: an attack on the agent meets a control the agent did not write.
- Session correlationAn attack assembled across turns is judged as one session (Pro and above)
- Third-party tool screeningMCP tool descriptions, agent cards and agent-to-agent messages screened before they are trusted
- Adversarial testing681 attack templates in five mutation classes; 120 canary probes on every deploy, with rollback on regression
Conducting AI-enabled defense
Focus area three: not what Shrike does.
- Where Shrike stopsShrike does not run AI-enabled defense on your behalf. It governs the agents you run and records what they did
- What it hands overVerdicts and incidents stream to Splunk, Microsoft Sentinel, CrowdStrike Falcon or a webhook, where your defense tooling reads them
NIST CSF 2.0 Control Map
| Subcategory | CSF 2.0 outcome | What Shrike does for it |
|---|---|---|
| GV.PO-01 | "Policy for managing cybersecurity risks is established based on organizational context, cybersecurity strategy, and priorities and is communicated and enforced" | Your policy is what Shrike enforces. Default policies apply on every tier and Enterprise adds custom rules. Each action is evaluated against the policy before it executes, and the record names the policy that applied. |
| PR.AA-05 | "Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties" | Declared scope: an agent states what it is for and the tools and paths it holds, and every action is checked against that scope. Widening needs a person. The agent cannot widen itself, and a refresh inherits the scope rather than re-asserting it. Fourteen action-plane controls sit behind this, from scope presence to approval override, including a guardrail control that holds any change to the agent's own hooks, settings and checks for a person. |
| DE.CM-09 | "Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events" | Pre-execution evaluation of shell commands, SQL, file paths and file contents, web searches, retrieved context, agent-to-agent messages and agent cards, on all six integration channels, with the nine-layer content pipeline behind the action controls. |
| DE.AE-02 | "Potentially adverse events are analyzed to better understand associated activities" | Every verdict names its tier (allow, warn, hold, block), the axis that objected (content or authorization), and the policy that applied. A hold says which question the action failed, so a reviewer can tell an injection from an overreach. |
| DE.AE-03 | "Information is correlated from multiple sources" | Session correlation across turns: requests are judged as a session, so an attack assembled over several messages is seen as one. Available on Pro and above. |
| DE.AE-08 | "Incidents are declared when adverse events meet the defined incident criteria" | Every block mints an incident carrying the verdict, the policy and the session. Repeat attempts amend the same incident instead of minting new ones. |
| RS.MA-04 | "Incidents are escalated or elevated as needed" | A held action escalates to a person. An action outside scope, or one that needs authority the agent does not hold, waits for an operator's decision on the Agents screen. The agent receives the reason and the recovery path, and the decision is recorded with who made it. |
| RS.AN-06 | "Actions performed during an investigation are recorded, and the records' integrity and provenance are preserved" | Each incident carries a timeline. Every status change is appended with the actor and the time, approvals record who approved and why, and the original verdict stays beside the changes rather than being overwritten. |
| PR.PS-04 | "Log records are generated and made available for continuous monitoring" | Every scan is persisted with its verdict, allows included. The audit trail and its CSV export are Enterprise features; event connectors deliver the same events to Splunk, Microsoft Sentinel, CrowdStrike Falcon or a webhook. |
| PR.DS-10 | "The confidentiality, integrity, and availability of data-in-use are protected" | Personal data found in prompts and responses is redacted, not blocked, so the task proceeds without the data. Prompt content is never written to service logs, and the semantic layer sees only the content the deterministic layers cannot decide. |
| ID.AM-02 | "Inventories of software, services, and systems managed by the organization are maintained" | The Agents screen is an inventory of every agent Shrike has seen, with its declared scope, its current status and its expired scopes retained, so an auditor can see what each agent was allowed to do and when that changed. |
| GV.SC-07 | "The risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship" | Third-party tools are screened before they are trusted: MCP tool descriptions at registration, for tool poisoning; agent cards in A2A discovery, for capability misrepresentation; and messages between agents, for instructions smuggled in transit. |
| ID.RA-01 | "Vulnerabilities in assets are identified, validated, and recorded" | Shrike's own detection is tested adversarially: 681 attack templates across five mutation classes, and 120 canary probes fired at every deployment. A deployment whose probes regress against the baseline is rolled back to the prior revision. |
Subcategory text is quoted from NIST CSF 2.0 (CSWP 29, February 2024). Where a subcategory is yours to satisfy, Shrike supplies the evidence, not the control.
Implementation Architecture
Shrike sits in the interval between an agent deciding on an action and the runtime carrying it out. Every tool call, command, query, file write and message to another agent is evaluated against your policy and the agent's declared scope before it executes, at the boundary you own: the SDK inside the agent, the MCP server, or the LLM gateway. A held action waits for a person. Every decision is recorded, allows included, and that record is what the reports and your auditor read.
Minimal Integration
SDK: three lines in the agent. MCP: a server entry. Gateway: a base URL.
Air-Gapped Deployment
Signed policy bundles, zero outbound. Available under Enterprise engagement on GKE Confidential Nodes
Cloud-Agnostic
GCP (live) · AWS (planned) · On-Prem (Enterprise)
Additional Framework Alignment
Year-1 target; audit vendor selection in progress
Roadmap; 3PAO not yet engaged
Meeting GPAI + Art. 50 transparency obligations; EU enforcement powers live Aug 2, 2026. Standalone high-risk (Annex III) follows Dec 2, 2027 (Digital Omnibus, in force 27 Jul 2026)
Mapped category by category, with the layer and the verdict for each: view mapping
Compliance Reporting
Enterprise customers generate compliance posture reports that map detected policy violations to control requirements across five frameworks, with per-control scoring and CSV export for auditors and GRC workflows.
Subprocessors
Required disclosure under GDPR Art. 28. Shrike uses the following subprocessors to deliver the service. Customer scan content is processed in transit only. See the Privacy Policy for retention details.
| Subprocessor | Purpose | Region | Data Class |
|---|---|---|---|
| Google Cloud Platform | Compute (Cloud Run) + database (Cloud SQL) | us-central1 (default); EU on request | All scan traffic + customer metadata |
| Google Cloud Vertex AI (Gemini) | Semantic (LLM) analysis, layer 7 of the pipeline | us-central1 | Content the deterministic layers cannot decide |
| Stripe | Subscription billing for Pro and Team tiers | US | Billing email + payment metadata (no scan content) |
| Google Workspace (Gmail SMTP) | Transactional email (signup, alerts) | US | Customer email address |
| GCP Marketplace / Cloud Commerce | Enterprise marketplace billing | US | Procurement account ID |
Enterprise customers receive 30-day advance notice of subprocessor additions or changes via the contractual notification process.
Security Posture & Disclosure
Incident History
No reportable security incidents to date.
Customer notification SLA: 24 hours from confirmation, per Pro/Team/Enterprise contract terms.
Vulnerability Disclosure
Report vulnerabilities to security@shrikesecurity.com.
Acknowledgment within 2 business days. Coordinated disclosure with credit. Formal bug bounty program on the roadmap; interim rewards handled case-by-case.
Common Questions
Does deploying Shrike make my AI app SOC 2 compliant?
No tool makes you SOC 2 compliant. Your auditor issues that opinion about your organization. What an auditor accepts is evidence that your controls operated. Shrike produces exactly that for the AI part of your stack: a per-action audit trail where every agent action is evaluated against your policy and every allow, warn, require-approval, and block is recorded and exportable. When a security questionnaire asks how you control what your AI can do, you answer with records instead of intentions. It shortens your path; it does not replace your audit.
How does Shrike help with the EU AI Act?
Shrike maps to the high-risk risk-management (Article 9) and transparency (Article 50) control expectations: pre-execution evaluation of agent actions, human-in-the-loop approval on consequential actions, and a retained per-action decision trail. Article 50 transparency obligations and GPAI enforcement powers are live as of August 2, 2026; standalone high-risk obligations follow on December 2, 2027. This is posture alignment and evidence, not certification.
What evidence can I hand my auditor or a customer security review?
A per-action record: what the agent attempted, the verdict (allow, warn, require-approval, or block), the policy that applied, who approved an override if one occurred, and a timestamp, retained and exportable, plus compliance reports mapped to HIPAA, GDPR, SOC 2, ISO 27001, and PCI DSS. Evidence packages and DPAs are available on request.
Does the evidence record depend on which model provider we use?
No. Enforcement runs at the SDK, MCP, or proxy boundary you own, so the policy, the agent scopes, and the per-action record are the same whether the model is OpenAI, Anthropic, Google, an open-weight model, or a local model served by Ollama or vLLM. The record exports to your SIEM and your auditor in the same shape when the provider changes, which keeps a provider migration from resetting your control evidence.
Is Shrike a guardian agent, in the sense Gartner uses the term?
Gartner uses guardian agents for the runtime layer that watches what AI agents do, enforces policy at the point of action, and produces an audit trail for review, within its AI TRiSM framework for trust, risk and security management. That is the function Shrike performs: every tool call, command, query and message is evaluated against your policy before it executes, held for a person when the action needs authority the agent does not hold, and recorded per action. The category as Gartner describes it also covers capabilities Shrike does not provide, such as identity and access management for agents; Shrike consumes the identity your platform already issues. Category placement describes function. It is not an analyst endorsement.
Ready to show your auditor what your agents did?
Ask for the evidence package, or a walkthrough of how the per-action record maps to your framework.
Last reviewed: 2026-09-15 · Evidence packages and DPAs: · Vulnerability disclosure: security@shrikesecurity.com
Shrike Security, Inc. · UEI YU85T9ZQ5ZB8 · CAGE 24DL9 · Registered in SAM.gov · Dallas, TX