Pennsylvania Treasurer’s DeepSeek AI Ban: What It Reveals About Government-Grade Cybersecurity, Vendor Risk, and the Future of Enterprise AI

What does it say about the state of AI security when a treasurer—someone tasked with safeguarding taxpayer dollars—steps in to ban a fast-rising AI platform across government devices? If you’re leading security, risk, data, or finance functions, the Pennsylvania Treasury’s decision to prohibit DeepSeek is more than a headline. It’s a signal flare for how public institutions (and highly regulated enterprises) will govern AI in 2025: with an uncompromising focus on provenance, supply chain integrity, and operational resilience.

In this post, we’ll breakdown what happened, why it matters, and how to build a pragmatic, secure AI adoption playbook that stands up to board scrutiny and red-team reality.

What Happened—and Why It Matters

Pennsylvania State Treasurer Stacy Garrity has banned the use of DeepSeek, a Chinese AI platform, on all Treasury devices, citing mounting cybersecurity risks amid its rapid global adoption. According to a report by The Global Treasurer, the directive mandates immediate removal and blocks future use due to concerns about data privacy, possible backdoors, and foreign adversary ties that could open doors to cyber espionage and supply chain compromise in financial operations. The decision surfaces broader fears about unverified AI models functioning like zero-day threats—hard to detect, easy to exploit, and attractive to advanced persistent threats (APTs).

Source: The Global Treasurer (Published: 2025-02-21)
Pennsylvania Treasurer bans DeepSeek AI over security concerns

Why it matters: – Government treasuries are high-value targets. They manage funds, debt, payments, tax flows, and sensitive citizen data—prime objectives for espionage and fraud. – The decision aligns with a broader U.S. trend of more stringent scrutiny of foreign-made digital tools in sensitive environments, especially when they combine high privilege with opaque or fast-moving supply chains. – It reinforces a growing enterprise norm: if model provenance, data handling, and runtime security aren’t provably robust, the correct control is deny-by-default.

The Cyber Risk Case Against Unvetted AI Models

The headline isn’t “AI is risky.” The headline is “opaque AI supply chains expand your blast radius.” Let’s unpack the primary threat surfaces that make unverified AI models a risky bet for state treasuries and regulated enterprises.

Backdoors and the AI Supply Chain

Model weights and artifacts: If you can’t verify where model weights came from, who touched them, and how they were built, you can’t rule out malicious alterations. Signed artifacts, reproducible builds, and verified provenance are must-haves.
Dependency sprawl: AI apps often pull in bindings, tokenizers, data loaders, CUDA/BLAS libraries, and pre/post-processing packages from public repos. A single hijacked dependency can yield code execution or data exfiltration (classic supply chain problem, amplified by AI’s pace).
Model and data provenance: Without lineage for training/fine-tuning data, it’s difficult to assess embedded risk (e.g., poisoned datasets that bias outputs or embed covert triggers).

Recommended references: – SLSA: Supply-chain Levels for Software Artifacts: https://slsa.dev/ – OpenSSF Scorecard: https://securityscorecards.dev/ – NTIA on SBOMs: https://www.ntia.gov/page/software-bill-materials

Credential Theft and Data Exfiltration

Sensitive prompts: Users often paste secrets (API keys, credentials, internal URLs) into LLMs. If the model or its telemetry is routed through untrusted infrastructure, you could be handing over the keys to the kingdom.
Implicit data collection: Some AI tools retain logs or samples for improvement. Without tight controls, data residency guarantees, and deletion SLAs, regulated data might leak beyond your control boundary.

Model-Level Threats Most Teams Underestimate

Weight tampering: Adversaries can subtly alter weights to:
Leak specific data when triggered by a particular token sequence
Weaken refusal policies
Bias outputs in financially harmful ways (e.g., misrouting payee instructions)
Fine-tune poisoning: Malicious instructions can be baked into downstream fine-tunes, introducing “sleeper behaviors” that may only appear under specific conditions.
Inference-time attacks: Prompt injection and indirect prompt injection can redirect tool-using agents to exfiltrate files, call destructive APIs, or retrieve secrets.

Helpful frameworks: – OWASP Top 10 for LLM Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/ – MITRE ATLAS (AI threat knowledge base): https://atlas.mitre.org/ – MITRE ATT&CK: https://attack.mitre.org/

Runtime and Integration Risk

SDKs and plugins: AI agents that call tools—file systems, email, payment rails, data warehouses—expand your attack surface. Any plugin with R/W privileges is a potential lateral movement pathway.
Native extensions: Python wheels with native code, GPU acceleration stacks, and unvetted container images carry classic RCE risk.

Why AI Risks Feel Like “Zero-Day”

Unverified AI behaves like a moving zero-day because: – Models are opaque: Even experts can’t fully “audit” weights. – Tooling is immature: Enterprise-grade provenance and attestation for ML is years behind general software supply chain controls. – Adversaries are motivated: APTs increasingly weaponize generative AI for phishing, malware scaffolding, and social engineering.

Context: – CISA AI and Secure-by-Design resources: https://www.cisa.gov/ai and https://www.cisa.gov/secure-by-design – Europol on LLM misuse for cybercrime (2023): https://www.europol.europa.eu/publication-events/publications/innovation-lab-spotlight-report-chatgpt

Why Governments and Financial Orgs Are Drawing a Line

The Data Is Too Sensitive—and the Stakes Too High

State treasuries handle taxpayer data, payment instructions, debt issuance details, and intergovernmental transfers. Even a modest data leak or covert manipulation of outputs could have outsized fiscal and reputational impact.

Regulatory and Policy Gravity

U.S. Executive Order on Safe, Secure, and Trustworthy AI (2023): Encourages safe development and deployment practices across the AI ecosystem.
EO on AI
NIST AI Risk Management Framework (AI RMF): A practical north star for governing AI risk in design, development, and deployment.
NIST AI RMF
NIST SP 800-53 Rev. 5 (security and privacy controls), still foundational for controls in sensitive systems.
NIST SP 800-53 Rev. 5
Sectoral obligations: For treasury-like operations, think GLBA overlaps for financial privacy, PCI DSS if cardholder data is touched, IRS Pub 1075 for federal tax information, and state privacy statutes.
PCI DSS: https://www.pcisecuritystandards.org/
IRS Pub 1075: https://www.irs.gov/pub/irs-pdf/p1075.pdf

Geopolitical Risk in Vendor Selection

Scrutiny of tools with potential foreign adversary ties is not new; many states have restricted certain foreign apps on government devices. When the technology is AI—where models can “see” sensitive data, reason over it, and call external tools—the risk calculus tightens dramatically. The Pennsylvania Treasury’s ban is consistent with a precautionary, provenance-first posture.

A Practical Playbook: How to Adopt AI Securely (Without Getting Burned)

Here’s a step-by-step approach you can implement now—regardless of whether you operate in the public sector or a heavily regulated industry.

1) Governance First: Policy, Inventory, and Data Rules

Create a system of record for AI usage:
Who is using AI? For what tasks? Via which tools? With what data?
Classify data for AI exposure:
Define “never share” categories (e.g., credentials, PII, FTI, payment instructions, security configs).
Establish a deny-by-default policy:
Only approved AI services/models are permitted. Everything else is blocked at the endpoint and network layer.
Define human-in-the-loop checkpoints where any AI output can affect financial transactions, compliance reporting, or public communications.

2) Vendor Due Diligence: Prove It or Lose It

Security certifications and posture:
FedRAMP Authorized (where applicable; verify on the official marketplace), SOC 2 Type II, ISO/IEC 27001.
FedRAMP Marketplace: https://marketplace.fedramp.gov/
SOC reporting (AICPA): https://www.aicpa.org/topic/audit-assurance/service-organization-reporting-sor
ISO/IEC 27001: https://www.iso.org/standard/27001
Model and data provenance:
Who trained/fine-tuned? What datasets? What filters? What governance controls were applied (model cards, datasheets)?
Model Cards: https://ai.googleblog.com/2019/12/model-cards-for-model-reporting.html
Supply chain transparency:
SBOMs for the app and runtime. Signed, reproducible builds. Secure container registries. External dependency disclosures.
Data handling:
Data residency options, encryption at rest/in transit (mTLS, TLS 1.2+), KMS with customer-managed keys, retention/deletion SLAs, and provable non-training commitments for your data.
Testing and attestation:
Regular independent pen tests, red-team exercises, and AI-specific security testing (jailbreak resistance, tool-use abuse scenarios, prompt injection resilience).

Bottom line: If a vendor can’t evidence these controls, it’s not ready for sensitive workloads.

3) Architecture: Limit Blast Radius by Design

Network isolation:
Private endpoints, VPC/VNet peering, no public egress for inference traffic when possible.
Egress controls and DNS filtering:
Block downloads of unsigned model weights. Force traffic through approved egress gateways with TLS inspection where policy permits.
Key and secret management:
Enforce short-lived tokens and scope-limited API keys; rotate on schedule and on any anomaly.
Data minimization:
Align prompts with least-privilege principles. Strip secrets from inputs with pre-processing where feasible.

4) Telemetry, SIEM, and Detection Engineering for AI

Log what matters: – Model identifiers, version/build hashes, and cryptographic attestations – Prompt/response hashes (or secure captures in protected logs), PII detection flags, guardrail events – Tool calls (who, what, when, result), file access, external API destinations – Data residency indicators, token usage, error rates, anomaly flags

Detect what’s risky: – Unusual egress to new model hosts or foreign infrastructure – Sudden spikes in data extraction from sensitive stores driven by AI agents – Downloads of large model files or containers from unapproved registries – Tool invocation patterns inconsistent with a user’s role (RBAC anomaly) – Known prompt injection signatures or jailbreak heuristics

Feed this telemetry to your SIEM and automate responses: – Quarantine suspicious sessions, rotate keys, revoke tokens, block endpoints, and open tickets automatically.

5) Secure SDLC for AI and Prompt Security

Treat prompts and system instructions as code:
Version control, code review, secrets scanning, and approval workflows.
LLM app scanning:
Check for indirect prompt injection risks (e.g., when pulling context from URLs, files, or email).
Guardrails and content filters:
Define allowed tools, prohibited patterns (credential operations, mass data exports), and escalation paths.

6) Red Teaming and Model Evaluation

Scenario-driven testing:
Can the model be tricked into revealing hidden system prompts?
Can it execute unintended tool calls (e.g., moving funds, changing payee addresses)?
Abuse and jailbreak testing:
Systematically evaluate jailbreak resilience and prompt injection handling.
Safety-efficacy balance:
Establish thresholds where safety controls do not degrade mission-critical accuracy unacceptably.

Leverage frameworks: – MITRE ATLAS for AI threat behaviors: https://atlas.mitre.org/ – OWASP LLM Top 10: https://owasp.org/www-project-top-10-for-large-language-model-applications/

7) Legal and Procurement Clauses That Actually Help

Data usage:
Explicit “no training on customer data” unless opt-in; detail logging scope and retention.
Residency/compliance:
Specify regions, regulatory mappings (e.g., GLBA-aligned controls, PCI DSS scope isolation), and audit rights.
Incident response:
24–72 hour notification SLAs; clear root cause reporting; key rotation and retraining commitments if leakage occurs.
Provenance and attestations:
Require signed models, SBOMs, dependency disclosures, pen test summaries, and security architecture diagrams.
Exit strategy:
Data export formats, guaranteed deletion timelines, and audit logs retained for a defined period.

8) People and Process: The Human Layer

Training:
Teach teams what never to paste into prompts and why. Provide safe alternatives (secrets managers, redacted context feeds).
Change management:
Roll out approved tools with clear guardrails, tips, and real use cases so shadow AI doesn’t take root.
Accountability:
Name an AI risk owner; define RACI for security, privacy, legal, and procurement across the AI lifecycle.

What Could You Use Instead? Sensible Alternatives to Unverified Models

If your organization needs AI now—but cannot stomach model provenance uncertainty—consider these categories. Always verify current certifications and claims:

Managed AI services with enterprise controls:
Major cloud platforms offer model hosting with VPC endpoints, KMS integration, logging, and rich access controls. Check for FedRAMP Authorized offerings where required:
FedRAMP Marketplace: https://marketplace.fedramp.gov/
Enterprise-grade model access via secure platforms:
Services that provide gated access to multiple foundation models, strong data-handling guarantees, and region control—potentially allowing you to avoid direct handling of raw model weights.
Open-source models with verified provenance, hosted securely:
Consider well-known OSS models delivered via trusted registries with signed artifacts, reproducible builds, and commercial support for patching and monitoring. Host them in your private environment with strict egress policies and SIEM integration.

Note: Vendor landscapes evolve quickly. Validate each provider’s current security attestations and data-handling posture before onboarding.

What This Means for AI Strategy in 2025

Provenance is product. If your AI vendor can’t prove model lineage, data safeguards, and supply chain integrity, it’s not enterprise-ready.
Centralize AI procurement. Decentralized AI tool adoption invites supply chain chaos, redundant spend, and shadow risk.
Build AI-specific detection and response. Traditional controls aren’t enough—your SIEM now needs AI telemetry, model attestations, and guardrail event logs.
Expect more public bans and procurement bars. Especially in government and finance, you’ll see risk-based policies that classify certain AI sources as off-limits.
Security is an enabler, not a brake. The fastest path to safe AI adoption is a clear, well-communicated control framework that helps teams ship responsibly.

A 30/60/90-Day Checklist to Operationalize Secure AI

Days 0–30: – Publish an AI acceptable use policy; enforce deny-by-default on unapproved tools – Inventory current AI usage; block unverified browser extensions and desktop apps – Stand up an AI steering committee (security, legal, privacy, data, procurement) – Define sensitive data categories and redaction rules for prompts

Days 31–60: – Shortlist enterprise AI platforms; begin vendor due diligence (FedRAMP/SOC 2/ISO 27001, SBOMs, data handling) – Pilot in a private network segment with KMS, logging, and egress controls – Implement AI telemetry and SIEM detection use cases (tool-call anomalies, egress spikes) – Train staff on prompt hygiene and secrets handling

Days 61–90: – Conduct AI red-team exercises (prompt injection, tool abuse, jailbreaks) – Finalize procurement clauses (no-train, residency, incident SLAs, provenance attestations) – Roll out approved AI to targeted teams; integrate with DLP and EDR – Establish quarterly AI risk reviews and patch/upgrade playbooks

Frequently Asked Questions

Q: Why did Pennsylvania’s Treasurer target DeepSeek specifically?
A: According to reporting, the ban centers on cybersecurity risks linked to data privacy, potential backdoors, and geopolitical exposure—all magnified by AI’s access to sensitive financial workflows. The directive is a precautionary move consistent with broader U.S. scrutiny of foreign-developed tools in high-stakes environments.

Q: Are open-source AI models inherently unsafe?
A: Not inherently. Open source can be a strength for transparency and community vetting. The risk arises when provenance, signing, build reproducibility, and runtime controls are missing. Many organizations safely deploy open-source models—privately hosted, with signed artifacts, network isolation, and robust monitoring.

Q: What does “model backdoor” actually mean?
A: A backdoored model has been altered so it behaves normally most of the time, but produces attacker-specified outputs (or leaks data) when triggered by a secret pattern. Because models are complex and opaque, detecting such tampering is non-trivial without strong provenance and attestation.

Q: Can prompt injection really cause data loss or fraud?
A: Yes—especially when AI agents can call tools. An attacker can craft content that, when ingested by the model (e.g., from a website or email), causes it to execute unintended actions like exporting data, forwarding sensitive emails, or initiating flawed workflows.

Q: What certifications should we look for in AI vendors?
A: Depending on your regulatory context: FedRAMP Authorization (for U.S. federal workloads or similar requirements), SOC 2 Type II, ISO/IEC 27001. Also evaluate data residency, encryption/KMS, SBOMs, pen test cadence, and clear no-train commitments for your data.

Q: Is this ban more about politics than security?
A: Regardless of geopolitical context, the security case stands on its own: opaque supply chains, uncertain model provenance, and potential for adversarial tampering raise the risk profile. Sensible risk governance demands stronger controls (or outright prohibition) until evidence of security is established.

Q: How do we enable innovation without inviting shadow AI?
A: Move fast on a safe default: approve one or two enterprise-grade AI platforms with clear guardrails, observability, and data protections. Make them easy to use. Communicate what’s allowed, what’s banned, and why—so teams don’t reach for risky tools.

Q: What frameworks can guide our AI risk program?
A: Start with the NIST AI RMF for governance and the OWASP Top 10 for LLM Apps for app-layer risks. Use MITRE ATLAS to understand adversary behaviors and CISA’s Secure-by-Design principles to harden your software lifecycle.
– NIST AI RMF: https://www.nist.gov/itl/ai-risk-management-framework
– OWASP LLM Top 10: https://owasp.org/www-project-top-10-for-large-language-model-applications/
– MITRE ATLAS: https://atlas.mitre.org/
– CISA Secure-by-Design: https://www.cisa.gov/secure-by-design

The Clear Takeaway

The Pennsylvania Treasury’s ban on DeepSeek is not a blanket indictment of AI—it’s a mandate for proof. In 2025, enterprise AI must come with verifiable provenance, strong data guarantees, hardened runtimes, and rich observability. Government treasuries and financial institutions can—and should—embrace AI’s productivity gains. But the path forward runs through security engineering, not around it.

If your AI stack can’t show its receipts—who built it, how it’s secured, how it’s monitored—assume the risk is unacceptable. When in doubt, deny by default, then build the controls that let you say yes with confidence.

Discover more at InnoVirtuoso.com

I would love some feedback on my writing so if you have any, please don’t hesitate to leave a comment around here or in any platforms that is convenient for you.

For more on tech and other topics, explore InnoVirtuoso.com anytime. Subscribe to my newsletter and join our growing community—we’ll create something magical together. I promise, it’ll never be boring!

Stay updated with the latest news—subscribe to our newsletter today!

Thank you all—wishing you an amazing day ahead!

Pennsylvania Treasurer’s DeepSeek AI Ban: What It Reveals About Government-Grade Cybersecurity, Vendor Risk, and the Future of Enterprise AI

What Happened—and Why It Matters