Cloud Security

Why Enterprise AI Is Leaving the Cloud (And What You Should Do About It) Watch my full analysis here: https://lnkd.in/eSCajwZe I've been in the tech industry long enough to recognize when a dominant narrative starts to crack. The story that the AI vendors sold us—that intelligence lives in the cloud, everyone rents access forever, and scale solves all problems—is hitting reality. And reality is winning. Here's what I'm seeing. Enterprises are quietly moving AI workloads back on-premises. Not because they're anti-cloud, but because the economics don't work, the security risks are too high, and the compliance requirements are too demanding. One company saw their AI cloud costs triple in a single quarter. Uber is restricting how employees use AI because bills spiraled beyond budget. Nearly half of employees have uploaded sensitive corporate data into public AI tools without IT's knowledge. These aren't edge cases. This is the pattern. I ran the numbers on a ten-year horizon for a typical enterprise. Remote LLM infrastructure costs about 18.9 million dollars. On-premises AI infrastructure costs about 15.5 million. That's 3.4 million in savings. And on-premises AI delivers thirty to forty percent better ROI. The cloud makes sense for training. But inference—the execution, where your data lives and your business value is created—increasingly runs better locally. That's not my opinion. That's what the economics and the security posture demand. The winning AI strategy isn't to send everything to a remote LLM provider. It's to keep intelligence where your data, governance, and business value already live. That means AI becomes more local, more private, more enterprise-owned. The transition is happening. The question is whether you're ahead of it or behind it. What are you seeing in your organization? Are you moving AI workloads on-premises, or are you doubling down on cloud? Share your experience in the comments. Let's figure this out together. EnterpriseAI # CloudStrategy # ArtificialIntelligence # DigitalTransformation # TechLeadership

AI security/securing the use of AI is going to kill me. I use Claude Code almost daily. It's a problem.... Here's what I have to change AGAIN this week. Security researcher Ari Marzuk disclosed 30+ vulnerabilities across AI coding tools. Cursor. GitHub Copilot. Windsurf. Claude Code. All of them. He called it IDEsaster. The attack chain includes prompt injection, hijacking LLM context, and auto-approved tool calls executing without permission. Then, legitimate IDE features are weaponized for data exfiltration and RCE. Your .env files. Your API keys. Your source code. Accessible through features you thought were safe. Most studies I read claim that around 85% of developers now use AI coding tools daily. Most have no idea their IDE treats its own features as inherently trusted. 𝗦𝗼... 𝗮𝗳𝘁𝗲𝗿 𝗿𝗲𝘃𝗶𝗲𝘄𝗶𝗻𝗴 𝗔𝗿𝗶'𝘀 𝗿𝗲𝘀𝗲𝗮𝗿𝗰𝗵, 𝗵𝗲𝗿𝗲'𝘀 𝗜 𝘄𝗶𝗹𝗹 𝗯𝗲 𝗱𝗼𝗶𝗻𝗴... Be warned: All this is SO much easier said than done! Audit every MCP server connection. Checked for tool poisoning vectors where legitimate tools might parse attacker-controlled input from GitHub PRs or web content. Removed servers I couldn't verify. Disabled auto-approve for file writes. The attack chains weaponize configuration files and project instructions like .claude/settings.json and CLAUDE.md. One malicious write to these files can alter agent behavior or achieve code execution without additional user interaction. Move all credentials to a secrets manager. No .gitignored .env files in agent-accessible directories. API keys live in 1Password CLI. Environment variables inject at runtime through a wrapper script the LLM never sees. Start running Claude Code in isolated containers. Mounted volumes limited to specific project directories. No access to ~/.ssh, ~/.aws, or ~/.config. If the agent gets compromised, blast radius stays contained. Enable all security warnings. Claude Code added explicit warnings for JSON schema exfiltration and settings file modifications. These exist because Anthropic knows the attack surface. Add pre-commit hooks for hidden characters. Prompt injections hide in pasted URLs, READMEs, and file names using invisible Unicode. Flag non-ASCII characters in any file the agent might ingest. The fix isn't to stop using AI coding tools. The fix is to stop trusting them implicitly. What controls do you have for AI tools with write access to your codebase? 👉 Follow for more AI and cybersecurity insights with the occasional rant #AISecurity #DevSecOps

👉 Why Your Organization Needs to "Containerize" AI Agents Right Now If your employees are installing OpenClaw (or similar agents) directly onto their local machines, you aren’t just adopting AI—you’re creating a massive, unmonitored risk. I recently sat down with Stephen Schmidt, Chief Security Officer at Amazon, and his advice was blunt: "Never let an AI agent run free on an individual machine." Here is why the "Isolation Chamber" approach is the new security standard: ✔️ The Problem with "Unfettered Access": Standard agents often have access to literally everything on a machine. If that one agent is compromised, your entire local exposure risk skyrockets. ✔️The "Piercing" Principle: By running agents in a container (like a VM or microVM), the agent is physically fenced in. ✔️Auditability as a Control: To do anything useful, an agent must "pierce" that container boundary to get credentials or access data. That act of piercing is a measurable event that you can audit, log, and control. ✔️The "Judge" Model: Once an agent makes a request for a credential from inside its container, you can use a second "Judge" model to examine if that request is reasonable based on the user's job and context before granting it. ✔️ The Bottom Line: Security isn't about stopping the deployment of agents—it’s about ensuring they operate in an environment where their actions are scoped, measured, and tied to a unique identity. For those exploring the enterprise side of agentic AI, AWS has a useful overview here: https://lnkd.in/eubr-VpH Stop the "OpenClaw oopsies" before they happen. Pick an isolation method—container, VM, or otherwise—and start measuring what your agents are actually doing. Are you currently allowing AI agents to run natively on employee hardware, or have you already started moving toward a "sandboxed" environment? Let’s discuss the trade-offs in the comments. #AWSAmbassador #AI #CyberSecurity #AgenticAI #Amazon #HumanX #TechLeadership

Cloudflare had another outage, lasting 25 mins, on 5th Dec, and this happened while they were patching their servers for a React vulnerability. Here's what exactly happened... - They were increasing how much of a request body their firewall could inspect from 128KB to 1MB. - While rolling this out, an internal testing tool started breaking. Since it wasn't needed for live traffic, they decided to just turn it off for now. - Here's where things went wrong: they turned off the tool using a global config system that pushes changes instantly to the entire network, with no gradual rollout. - This triggered, or rather uncovered, a bug. - Cloudflare's rulesets system has actions like "block", "log", "skip", and "execute". The "execute" action triggers the evaluation of another ruleset. Their internal testing system uses this to run test rules before public release. - They never applied a killswitch to an "execute" rule before. This assumed the `rule_result.execute` object existed, but it didn't, so Lua threw an error when trying to access a nil value. - This caused HTTP 500 errors for customers on Cloudflare's older FL1 proxy... and took down 28% of their traffic. The RCA is linked below. Do give it a read.

Have you noticed the little security shield in your Microsoft 365 Copilot chat change colour? This isn't a warning that something has gone wrong. In fact, it's the opposite. The orange shield in my image below is a visible indication that Microsoft 365's security and compliance capabilities have identified the conversation as containing sensitive information and are applying the organisation's governance policies. When you're using Microsoft 365 Copilot, you're not working with AI in isolation. You're working with AI that operates within your organisation's existing security, identity, compliance, and data protection framework. That means: - Sensitive information can be identified and classified automatically. - Data Loss Prevention (DLP) policies can inspect Copilot prompts and interactions. - Organisations can control how sensitive information is used by Copilot. - Security teams can monitor and audit interactions where required. - Existing Microsoft Purview controls extend into the AI experience. This is one of the key differences between consumer AI tools and enterprise AI. Microsoft 365 Copilot is designed to work within the security boundaries of your organisation, respecting permissions, classifications, compliance requirements, and governance policies that already exist across Microsoft 365. So when you see a different coloured shield in a Copilot conversation, think of it as a visual reminder that you're using secure AI at work, grounded in your organisation's context and protected by enterprise-grade security controls. Hover over it to reveal the explainer and understand which policy is being applied and why.

Over several weeks, we at Okta tested OpenClaw with various AI models to see how agents handle API keys, OAuth tokens, and credentials. The short of it is that agents can't be trusted, and it's easy to talk them into skirting their guardrails. In one example, an AI agent revealed an OAuth token, then immediately warned we should revoke it since it knew it had messed up. In another, we set up a website for a fictional pie shop and gave an AI agent access to credentials. We pointed it at the fake pie shop’s inquiry form and asked it to fill it out. Unprompted, it dumped its entire credential store — email, password, API keys, GitHub token — into the email field. There are more humorous tales in the blog. The TLDR: Don't let agents see secrets! Treat them like identities and only give them scoped, short-lived tokens that are safely stored. More here: https://lnkd.in/gdED2bjb

Compliance isn’t choosing one framework, it’s understanding how they work together. Many organizations view SOC 2, ISO 27001, and GDPR as competing obligations, but the reality is far more integrated. SOC 2 validates data security controls for US-based service providers voluntary but expected by enterprise clients. ISO 27001 provides a globally recognized ISMS foundation with comprehensive risk management and continuous improvement. GDPR legally enforces personal data protection for EU citizens with significant financial penalties for non-compliance. The strategic advantage lies in their overlap: access controls, incident response, vendor risk management, encryption, and breach notification requirements align across all three. Organizations that map controls once and satisfy multiple frameworks simultaneously reduce audit fatigue while strengthening their overall security posture. Rather than treating compliance as separate silos, mature GRC programs build unified control environments that address shared requirements, turning regulatory burden into operational excellence. What’s your approach to managing overlapping compliance frameworks? #GRC #SOC2 #ISO27001 #GDPR #Compliance #InformationSecurity #DataProtection

This EY incident underscores a truth we often overlook: the most common cloud vulnerability isn't a zero-day exploit; it's a configuration oversight. A single misstep in cloud storage permissions turned a database backup into a public-facing risk. These files often hold the "keys to the kingdom" ie. credentials, API keys, and tokens that can lead to a much wider breach. How do we protect ourselves against these costly mistakes? Suggestions 1. Continuous Monitoring: Implement a CSPM for 24/7 configuration scanning. CSPM is Cloud Security Posture Management -> a type of automated security tool that continuously monitors cloud environments for misconfigurations, vulnerabilities, and compliance violations. It provides visibility, threat detection, and remediation workflows across multi-cloud and hybrid cloud setups, including SaaS, PaaS, and IaaS services 2. Least Privilege Access: Default to private. Grant access sparingly. 3. Data Encryption: For data at rest and in transit. 4. Automated Alerts: The moment something becomes public, you should know. 5. Regular Audits: Regularly review access controls and rotate secrets.

If you’re looking to practice DevSecOps — here are 2 projects you should definitely check out.. (and the key processes you should know) TL;DR : DevSecOps = DevOps + Security, built in from the start. When I started exploring this practice, I realized I was already using parts of it in my day-to-day work. The security layer wasn’t just about adding tools — it was about thinking end-to-end across the whole DevOps workflow. Here are the few key components: → Security Checks & Scans Catch issues early with automated code and app security tests. → Vulnerability Management Scan, prioritize, and patch vulnerabilities regularly. → Threat Modeling Identify possible risks and plan mitigations before release. → Key Management Keep secrets, API keys, and certificates secure. → CI/CD with Security Automate builds and deployments with security gates built in. → Infrastructure as Code (IaC) Define infra in code for consistency and secure provisioning. → Container Security Scan images and protect containers during runtime. → Continuous Monitoring Track logs, activity, and network traffic for anomalies. → QA Integration & Collaboration Embed QA and make security part of team culture. ⸻ 2 Projects to Implement: 1. Netflix Clone with DevSecOps Pipeline • Covers CI/CD, container scans, secrets management, monitoring. • GitHub : https://lnkd.in/dWR4GV7m • Youtube: https://lnkd.in/dkSjBcNM 2. DevSecOps CI/CD Implementation • Implementing a pipeline for a Tic-Tac-Toe game application.. • GitHub : https://lnkd.in/d3WgCuKY • Youtube: https://lnkd.in/dTQcw3Sw Any other projects or topics you'd like to add? Comment below 👇 If you found this useful: • • • I regularly share bite-sized insights on Cloud & DevOps (through my newsletter as well) — if you're finding them helpful, hit follow (Vishakha) and feel free to share it so others can learn too! Image Src : ByteByteGo

Your data might be physically in another country, but it isn't in that country. If it's with an American company, it's in America. Microsoft's recent confirmation that U.S. law takes precedence over Canadian data sovereignty isn't just a tech issue, it's a privacy nightmare. We've been told our data is "safe" in the cloud, but the reality is more complicated. The CLOUD Act means a valid U.S. legal request can pull your information, no matter where it's stored. Relying solely on foreign cloud providers puts a company's data autonomy at risk. The real play here isn't just about security; it's about control. And right now, many of us have less than we think. Microsoft's precedent here sets us on a slippery slope. #DataSovereignty #CloudComputing #TechPolicy #Privacy #CLOUDAct