DEV Community: Ali-Funk

Beyond the Playbook: Architecting Defenses Against Autonomous AI Threats

Ali-Funk — Mon, 06 Jul 2026 21:15:07 +0000

Beyond the Playbook: Architecting Defenses Against Autonomous AI Threats

We used to build security systems assuming the attacker was human.

That assumption just died.

Recent research demonstrations involving autonomous AI agents, such as "JadePuffer", have shown how quickly this shift is happening: an autonomous system independently compromised an unsecured Langflow instance, corrected failed authentication attempts, escalated privileges, exfiltrated credentials, and deployed ransomware — all without human intervention.

This is not a one-off curiosity. It marks the beginning of a fundamental change in the threat landscape.

From Static Playbooks to Autonomous Attackers

Traditional ransomware follows predictable patterns. A script runs through a fixed playbook: scan, encrypt, demand ransom. If one step fails, the attack often stalls.

Autonomous AI agents operate differently. They analyze their environment in real time, adapt when initial attempts fail, make contextual decisions about targets and techniques, and chain multiple exploits together without predefined sequences.

This introduces machine-speed lateral movement.
Something human defenders and traditional security tools are not built to handle.

The Defensive Automation Gap

The core problem is asymmetry.

Attackers are rapidly automating both reconnaissance and execution. Defenders, on the other hand, still rely heavily on manual processes, static rules, and human-driven response. This "Defensive Automation Gap" creates dangerous imbalances in speed, scale, and adaptability.

When an autonomous agent can pivot from a compromised web application to domain admin rights in minutes, waiting for a SOC analyst to investigate is no longer viable.

Architectural Implications for Enterprise Security

This development forces us to rethink several foundational elements of security architecture.

Internal trust is beginning to collapse.

An agent inside your environment can no longer be assumed benign simply because it originated from an internal system. Every agent-to-agent or agent-to-service interaction now requires explicit verification.

Identity Is the New Perimeter (Again)

Machine identities — especially autonomous ones — must be treated with the same rigor as human identities. This includes short-lived credentials, strict least privilege, continuous behavioral validation, and workload isolation.

Immutable Infrastructure Becomes Essential

If an autonomous attacker compromises a workload, “cleaning” the system is often too slow. The correct response is to treat compromised nodes as disposable: destroy and replace them automatically from a trusted, immutable source.

Microsegmentation at Machine Speed

Traditional network segmentation is no longer sufficient. We need programmatic, API-level Zero Trust controls capable of reacting instantly to anomalous behavior between services and autonomous agents.

Automated Detection and Response

Security systems must match the speed of the attacker. This means investing in runtime monitoring, behavioral analysis, and automated containment that can isolate threats before human analysts even begin triage.

The Strategic Shift for Security Architects

Security architects can no longer focus solely on prevention and static controls. The new mandate is systemic resilience — designing environments that assume autonomous threats will occur and can recover gracefully while maintaining business continuity.

This requires a fundamental mindset shift:

From “prevent all breaches” to “contain autonomous compromise at machine speed”
From manual playbooks to adaptive, automated defense systems
From perimeter-focused security to identity- and behavior-centric architectures

Conclusion

The age of autonomous AI threats is no longer theoretical.

Organizations that continue treating security as a static checklist will find themselves increasingly vulnerable to adversaries that operate faster than their defenders can react.

Future security architectures will be judged less by whether they prevent breaches — and more by how fast they contain autonomous compromise.

The playbook is no longer enough. We must architect for autonomy.

On both sides of the battlefield.

Sources:

Sysdig Threat Research Team: JADEPUFFER: Agentic ransomware for automated database extortion
Link: https://www.sysdig.com/blog/jadepuffer-agentic-ransomware-for-automated-database-extortion

University of Illinois Urbana-Champaign: LLM Agents can Autonomously Hack Websites
Link: https://arxiv.org/pdf/2402.06664

Cornell Tech / Technion: Here Comes The AI Worm: Unleashing Zero-click Worms that Target GenAI-Powered Applications (The Morris II Generative AI Worm)
Link: https://arxiv.org/html/2403.02817v2

OWASP Top 10 for Large Language Model Applications
Link: https://owasp.org/www-project-top-10-for-large-language-model-applications/

Identity Is the New Perimeter: Why AI Agents Break Zero Trust

Ali-Funk — Sat, 04 Jul 2026 21:42:44 +0000

For years, Zero Trust architectures were designed around one assumption:
Humans make the decisions.

That assumption is breaking apart.

Autonomous AI agents can now query databases, trigger workflows, call APIs, and interact with other systems without direct human involvement. Modern AI systems no longer just generate text. They execute actions inside enterprise environments.

When an AI agent can operate on behalf of a user inside your cloud infrastructure, its identity becomes just as critical as any human identity.

And that fundamentally changes the security model.

The Rise of Tool Calling

Platforms like Amazon Bedrock Agents have changed the architecture of enterprise AI.

These systems can now interpret a user request, decide which tools are required, and autonomously execute backend operations through Lambda functions, APIs, databases, and external services.

A simple prompt can trigger an entire chain of actions.

Example Workflow
User Prompt:
"Summarize customer complaints from the last 30 days."

Agent Actions:

Query the CRM database

Call the analytics API

Pull support ticket data

Generate a report

Powerful for productivity.
Extremely dangerous if not properly secured.

The New Attack Surface

A single successful prompt injection can completely hijack an agent’s behavior. With overly broad permissions, an attacker can force it to:

Access sensitive customer data
Execute unauthorized API calls
Modify records
Trigger privileged backend workflows

The risk becomes even worse in multi-agent systems. A compromised customer-facing agent can pass malicious instructions to a highly privileged backend agent.

Traditional network perimeters and security tools often miss this entirely because the traffic comes from a trusted internal service.

Why Traditional Zero Trust Falls Short

Classic Zero Trust was designed for human behavior and relatively predictable access patterns. AI agents operate differently:

They act autonomously and at machine speed
They make decisions without real-time human validation
They frequently communicate with other agents

Security systems now need to answer much harder questions:

Is this action reasonable for this specific agent?
Does this request match its intended role?
Is this AI-to-AI interaction legitimate?
Does the behavior deviate from normal patterns?

Authentication alone is no longer enough.

How to Actually Secure AI Agents

Treating AI agents like regular IAM users is not sufficient. Security must be engineered directly into the architecture.

Use Short-Lived Credentials Only

Every agent execution should receive temporary credentials through AWS STS. Long-lived credentials create persistent attack paths.

Apply True Least Privilege

Each agent should have a dedicated IAM role with tightly scoped permissions only the exact Lambda functions, APIs, and databases it needs.

Eliminate Static API Keys

Hardcoded credentials should never exist in AI workflows. Use Workload Identity Federation + OIDC to let agents assume temporary roles dynamically.

Aggressively Isolate Agent Workflows

Run agents in separate VPCs or accounts to limit the blast radius of a compromise. Micro-segmentation is critical in autonomous environments.

Continuously Monitor Agent Behavior

Use CloudTrail, GuardDuty, and behavioral analytics to detect anomalies in tool usage, privilege escalation, and cross-agent communication.

The New Reality of Identity Security

Machine identities are growing exponentially. The future of cloud security is no longer just about protecting employees,it’s about governing autonomous systems operating at machine speed.

Organizations that succeed will treat AI agents as first-class identities with dynamic authorization, strict isolation, continuous verification, and real-time behavioral monitoring.

If we fail to extend Zero Trust to these systems, we are not modernizing security.
We are simply automating our own vulnerabilities.

In the age of autonomous AI, identity is the new perimeter even when that identity is not human.

Sources and Further Reading:

AWS Security Blog: Securing Generative AI Architectures
OWASP Top 10 for Large Language Model Applications
NIST Artificial Intelligence Risk Management Framework

Non-Human Identities: The Silent Attack Surface No One Is Monitoring

Ali-Funk — Mon, 22 Jun 2026 06:51:42 +0000

Most organizations know exactly how many employees they have.

Far fewer know how many non-human identities currently have access to their cloud environment.

That blind spot is becoming one of the fastest-growing attack surfaces in modern security.

For years, enterprise security focused primarily on protecting human identities. We deployed Single Sign-On (SSO), enforced Multi-Factor Authentication (MFA), and implemented Conditional Access policies. And it worked — human identities have become significantly harder to compromise.

Meanwhile, another class of identities has quietly exploded across cloud environments: service principals, workload identities, OAuth applications, CI/CD runners, and AI service roles.

Today, these Non-Human Identities (NHIs) often outnumber human users by a factor of 10 to 50. As organizations accelerate cloud adoption and integrate AI into daily operations, this imbalance continues to grow.

Defining the Non-Human Identity Landscape

Unlike human users, machine identities rarely appear in HR systems or organizational charts. Yet they frequently hold some of the most privileged access in the environment.

Common high-risk categories include:

OAuth Applications and Third-Party Integrations —

Apps granted broad access to Microsoft 365, Salesforce, Google Workspace, or Slack via delegated permissions.

Service Principals and Managed Identities —
AWS IAM roles, Azure Managed Identities, and GCP service accounts used by Lambda functions, EC2 instances, or Bedrock agents.
Workload Identities —
Kubernetes Service Accounts (e.g., Amazon EKS) and GitHub Actions OIDC roles.
CI/CD Pipeline Identities —
Tokens used by automation platforms to deploy infrastructure.
AI Service Roles —
Dedicated identities for Amazon Bedrock agents, model invocation, vector stores, and retrieval pipelines.

Every new AI workflow creates additional machine identities.

Why Attackers Are Targeting NHIs

Attackers follow the path of least resistance. While human accounts are now heavily protected, machine identities often suffer from:

Privilege Creep

Broad permissions granted during development frequently remain in place long after they are needed.
Lack of Visibility

Many organizations have no complete inventory of active service roles, OAuth grants, or workload identities.
Long-Lived Credentials

Static access keys and unrotated refresh tokens create persistent backdoors.

Real incidents like the 2025 Drift/Salesloft OAuth compromise have shown how dangerous this can become.

Building a Machine Identity Security Strategy

Securing NHIs requires treating them as first-class citizens in your security program:

Enforce Workload Identity Federation

Replace long-lived access keys with short-lived tokens using OpenID Connect (OIDC). AWS, Azure, and GCP all support this natively.

Continuous Monitoring and Discovery

Use tools like AWS IAM Access Analyzer, CloudTrail, Security Hub, and third-party NHI platforms to maintain visibility and detect anomalous behavior.

Automate Least Privilege

Regularly review and tighten policies. Unused permissions should be removed automatically.

Govern AI Identities Explicitly

AI services like Amazon Bedrock create powerful new identities. These must be inventoried, monitored, and restricted from the start.

The New Security Frontier

Enterprise security has evolved through multiple eras:

Networks → Endpoints → Human Identities.

The next frontier is Non-Human Identities

In the age of AI agents, serverless architectures, and autonomous cloud workflows, attackers no longer need to compromise an employee. Sometimes all they need is a single token.

The firewall is no longer the perimeter.

Identity is the perimeter.

And increasingly, that identity is not human.

This article is part of a series on practical cloud security in the AI era.

Previous: [Building a Serverless Security Monitoring Pipeline for AWS Bedrock]

References

AWS IAM Best Practices
AWS Well-Architected Framework – Security Pillar
AWS IAM Access Analyzer
Non-Human Identity Security Reports (Cyera, Wiz, Palo Alto Networks)

Building a Serverless Security Monitoring Pipeline for AWS Bedrock

Ali-Funk — Mon, 15 Jun 2026 08:53:53 +0000

CloudTrail records thousands of events every day, but security teams rarely notice a critical action until they actively investigate an incident.

What happens if someone disables logging?
What happens if an AI model is invoked unexpectedly?
What happens if a high risk administrative action occurs outside normal business hours?

Over the last two days, I built a fully serverless monitoring pipeline that detects high risk AWS events and generates near real time alerts using CloudTrail, Amazon S3, AWS Lambda, and Amazon SNS. This project was not just about connecting services. It was about building a reliable detection pipeline capable of processing real CloudTrail data, handling unexpected log formats, and generating actionable alerts automatically.
Architecture Overview

The solution follows a clean serverless pattern:
CloudTrail → Amazon S3 → AWS Lambda → Amazon SNS → Email Notification

CloudTrail continuously records management and data events. When a new log file lands in S3, it triggers a Lambda function. The function parses the events, evaluates them against detection rules, and sends alerts via SNS when a high risk action is detected.

Example Detection Flow

User invokes Amazon Bedrock model
↓
CloudTrail records InvokeModel event
↓
Log delivered to Amazon S3
↓
Lambda parses the event
↓
Detection rule matches
↓
SNS sends security alert

Security Use Cases

The pipeline currently monitors high impact events such as:

DeleteTrail
StopLogging
UpdateTrail
CreateTrail
InvokeModel (Amazon Bedrock)

These events are especially critical because they can reduce visibility, change auditing configurations, or indicate unauthorized usage of AI services.

Event Processing Logic

import json
import gzip
import boto3

# Handle varying CloudTrail structures
records = log_data.get('Records', []) if isinstance(log_data, dict) else [log_data]

Engineering Challenges

-Incorrect Log Compression Format: I encountered repeated UnicodeDecodeError exceptions. The root cause was that test logs were compressed with 7z instead of gzip. CloudTrail processing expects gzip.

-Lambda Console Syntax Errors: Editing Python code directly in the browser led to Runtime.UserCodeSyntaxError due to indentation issues. Lesson: Develop locally and deploy via ZIP or IaC.

-Dynamic JSON Structures: CloudTrail log formats vary. The solution was a defensive parser that gracefully handles different structures.

Future Improvements

EventBridge integration for advanced routing
Security Hub findings generation
Slack or Teams notifications
Automated remediation workflows
Risk scoring for detected events
Additional Bedrock specific detections

Conclusion

Cloud security monitoring is often presented as a tooling problem. In reality, it is an engineering problem. CloudTrail, Lambda, SNS, and Bedrock were relatively easy to connect. Building a pipeline that could reliably process real world data, survive unexpected failures, and generate actionable alerts was the actual challenge.

As organizations continue adopting AI services, visibility into cloud activity becomes increasingly important. Automated monitoring pipelines like this provide a practical foundation for detecting high risk events before they become security incidents.

As someone transitioning from enterprise infrastructure and support into cloud security, projects like this provide valuable hands on experience with AWS monitoring, automation, and security operations.

References

-AWS Lambda Developer Guide:
https://docs.aws.amazon.com/lambda/latest/dg/lambda-python.html

-AWS CloudTrail Event Reference:
https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference.html

-Amazon Bedrock Documentation: https://docs.aws.amazon.com/bedrock

-AWS Well Architected Framework:
https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html

Shadow AI and OAuth: Why the OAuth Token Is Now Your Biggest Blind Spot

Ali-Funk — Tue, 09 Jun 2026 08:50:18 +0000

For decades, Shadow IT lived on the network: the rogue server under a desk, the unauthorized SaaS subscription bought with a corporate card, or the wireless access point plugged in without approval. Security teams knew how to respond.Scan networks, block IPs, disable ports, and tighten firewall rules.

Today, Shadow IT has evolved. It no longer lives on the network.

It lives inside delegated identity permissions granted through OAuth. These non-human identities (NHIs) are rapidly becoming one of the fastest-growing attack surfaces in enterprise environments.

Most organizations still aren’t monitoring them.

The Perimeter Has Moved

The explosion of AI productivity tools has changed how enterprise data leaves the organization. Employees no longer need to install software or provision infrastructure. They simply click “Sign in with Microsoft” or “Sign in with Google.”

Within seconds, a third-party application receives broad delegated access to corporate resources. The firewall sees nothing. Endpoint detection reports no anomalies. No malware runs. No suspicious connections appear.

Yet that application may now hold persistent access to email, OneDrive, SharePoint, calendars, Teams, Google Drive, and other critical systems.

The traditional perimeter hasn’t shifted — it has been quietly bypassed.

Figure 1: Modern AI SaaS integrations bypass traditional network controls by establishing persistent OAuth trust relationships. The refresh token — not the firewall — is now the critical security boundary.

The Core Problem: Delegated Trust and Non-Human Identities

OAuth was designed to solve a legitimate problem: users shouldn’t share passwords with every app. Instead, identity providers issue scoped tokens.

This model works well — until modern AI platforms demand deep access to deliver value. An AI assistant cannot summarize emails it cannot read, organize documents it cannot access, or automate workflows it cannot see.

As a result, many AI tools request broad permissions such as:

Mail.ReadWrite
Files.Read.All
Calendars.ReadWrite
offline_access (often the most dangerous)

The offline_access scope grants long-lived refresh tokens that survive password resets, MFA changes, and even delayed offboarding. These become persistent non-human identities — alongside service principals, workload identities, API keys, and automation accounts.

As AI adoption accelerates, the number of these identities is growing far faster than the number of employees.

What the employee sees: a helpful productivity tool.

What security teams should see: a persistent trust relationship with an external entity operating outside traditional governance.

The Anatomy of an AI OAuth Exploit

An operations manager discovers an AI platform promising automated meeting summaries, document classification, and customer sentiment analysis. The website looks professional, reviews are strong, and the company appears legitimate.

She signs in with her corporate Microsoft account and grants the requested permissions.

Nothing malicious happens that day. The tool works as advertised.

But from that moment, part of the organization’s security posture now depends on the vendor’s security maturity. If the vendor is breached, leaks refresh tokens, or falls victim to a supply-chain attack, the blast radius can be severe.

No phishing. No endpoint compromise. No stolen credentials.

The attacker simply inherits already-granted trust.

Real-World Precedent: The Drift/Salesloft Attack

This is not theoretical.

In 2025, UNC6395 threat actors compromised OAuth tokens tied to Drift (later acquired by Salesloft). Using legitimate access, they reached Salesforce environments across hundreds of organizations. The integrations were trusted. The tokens were valid. Traditional controls missed the abuse.

Recent data underscores the scale: ~87% of applications in the average enterprise are unmanaged, only ~21% sit behind SSO, and AI tool adoption surged 181% in 2025.

Why Traditional IAM Breaks Here

Most IAM strategies focus on human-to-system interactions with Conditional Access evaluating location, device compliance, and risk signals.

OAuth flips the model. After initial consent, interactions become system-to-system. An AI platform can make thousands of API calls at 3 AM from a foreign cloud IP and still appear legitimate.

This creates a dangerous blind spot: strong human identity controls paired with minimal visibility into delegated applications.

Hardening the Identity Perimeter

Security teams must treat delegated permissions and non-human identities as core parts of the attack surface.

1. Restrict End-User Consent

Require administrative approval for apps requesting sensitive scopes (Files.Read.All, Mail.ReadWrite, offline_access, etc.). Evaluate vendor reputation, business need, and permissions before granting.

2. Enforce Least Privilege

Challenge broad permissions. Push vendors for granular scopes, resource-specific access, and time-limited tokens.

3. Continuously Audit Active Tokens and Applications

Maintain ongoing visibility into:

Active OAuth apps and non-human identities
Refresh token usage
API call patterns and volumes
Permission changes
Abnormal data access behavior

Monitor long-lived apps with the same rigor as privileged accounts.

4. Automate Revocation and Response

Build playbooks for rapid token revocation, app disabling, and investigation. Manual processes don’t scale against fast-moving threats.

The New Perimeter Is Identity

Enterprise security has evolved: networks → endpoints → identity.

The next frontier is delegated identity and non-human identities.

Organizations should embrace AI tools — they deliver real value. But innovation without visibility creates unmanaged risk.

The firewall is no longer the perimeter.
The endpoint is no longer the perimeter.
The OAuth token is the new perimeter.

In the age of AI, trust is no longer granted only to people.

It is granted to software.

References

Cyera — The Stealthy Rise of OAuth Application Risk: Why Non-Human Identities Are the New Security Frontier

https://www.cyera.com/blog/the-stealthy-rise-of-oauth-application-risk-why-non-human-identities-are-the-new-security-frontier

Zylo — What Are Unmanaged SaaS Apps? Risks, Examples, and How to Manage Them

https://zylo.com/blog/what-are-unmanaged-saas-apps-risks-examples-and-how-to-manage-them

IETF RFC 9700 — OAuth 2.0 Security Best Current Practice

https://datatracker.ietf.org/doc/html/rfc9700

Microsoft Entra ID — Manage Application Consent and Permissions

https://learn.microsoft.com/en-us/entra/identity/enterprise-apps/configure-user-consent

Google Workspace Admin — Control Third-Party App Access

https://support.google.com/a

Google Threat Intelligence — Widespread Data Theft via Salesloft Drift

https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift

Palo Alto Networks Unit 42 — OAuth Abuse and Compromised Salesforce Instances

https://unit42.paloaltonetworks.com

OWASP Top 10 for LLM Applications

https://genai.owasp.org

Explainable AI: The Missing Security Layer in Enterprise Cloud Deployments

Ali-Funk — Thu, 04 Jun 2026 13:44:10 +0000

For decades, cybersecurity has been built around a simple principle:

You cannot secure what you cannot see.

We monitor network traffic. We inspect logs. We audit identities. We track API activity and endpoint behavior because visibility enables control.

Yet as organizations rapidly deploy generative AI into cloud environments, many are introducing a new component into their architecture that operates very differently from traditional software:

The model itself.

Unlike conventional applications, modern AI systems often function as black boxes. We know what data enters the model and we can observe the output, but understanding why a specific decision was made is frequently difficult.

As someone whose professional background is rooted in infrastructure engineering and cloud operations, I recently started exploring the field of Explainable AI (XAI). What immediately caught my attention was how closely its goals align with the fundamental principles of security architecture: visibility, accountability, observability, and trust.

The more I researched the topic, the more convinced I became that Explainable AI is not simply an academic discipline.

It is rapidly becoming a critical security capability.

The Black Box Problem

Traditional software is largely deterministic.

When a system behaves unexpectedly, engineers can inspect source code, review logs, trace execution paths, and identify the root cause.

AI systems introduce a fundamentally different challenge.

Large Language Models (LLMs) and other deep learning architectures make decisions through billions of interconnected parameters. While the output may appear reasonable, understanding the exact reasoning behind a specific response can be significantly more difficult.

This creates a problem for security teams.

If an AI-powered system:

Produces an unexpected recommendation
Generates misleading information
Leaks sensitive business data
Demonstrates biased behavior
Makes decisions affecting customers or employees

Security and governance teams must be able to investigate what happened and why.

Without visibility into the model's reasoning process, incident response becomes significantly more difficult.

Why Traditional Security Controls Are Not Enough

Organizations continue investing heavily in:

Zero Trust architectures
Identity and Access Management (IAM)
Endpoint Detection and Response (EDR)
Security Information and Event Management (SIEM)
Cloud Security Posture Management (CSPM)

These controls are essential.

However, none of them explain why an AI model arrived at a particular conclusion.

A firewall can tell you who connected.

An IAM platform can tell you who authenticated.

A SIEM can tell you that something unusual happened.

None of them can explain why a model approved a transaction, recommended a medical diagnosis, flagged a customer, or generated a potentially harmful response.

This is where Explainable AI becomes relevant from a security perspective.

Explainability as Security Telemetry

One of the most interesting ways to think about XAI is as a new form of telemetry.

Security professionals already rely on telemetry to understand systems.

Logs tell us what happened.

Metrics tell us how systems behave.

Traces help us understand complex application flows.

Explainability provides similar visibility into AI systems.

Techniques such as feature attribution help identify which inputs influenced a model's output most strongly.

More advanced approaches, including mechanistic interpretability research, attempt to understand how internal neural network components contribute to specific behaviors.

While explainability does not eliminate security risks, it provides investigators with something they currently lack:

Context.

And context is often the difference between identifying a threat and missing it entirely.

Security, Governance, and Regulatory Pressure

The need for explainability extends beyond cybersecurity.

Organizations operating in healthcare, finance, insurance, government, and critical infrastructure increasingly face regulatory requirements surrounding transparency and accountability.

Frameworks such as the NIST AI Risk Management Framework and the EU AI Act place growing emphasis on explainability, governance, risk assessment, and human oversight.

This trend is unlikely to reverse.

As AI systems gain influence over business operations and decision-making processes, regulators will continue demanding greater visibility into how those decisions are produced.

A model that cannot be explained becomes difficult to audit.

A model that cannot be audited becomes difficult to trust.

Explainability Does Not Mean Perfect Understanding

One misconception I encountered while researching XAI is the assumption that explainability will somehow reveal every detail of a model's reasoning process.

The reality is more nuanced.

Explainability is not a magic solution.

It does not guarantee fairness.

It does not eliminate bias.

It does not automatically prevent prompt injection attacks or model manipulation.

What it does provide is a significantly better understanding of model behavior than having no visibility at all.

For security teams, that visibility is invaluable.

The Future of AI Security

Artificial intelligence is rapidly becoming part of enterprise infrastructure.

Organizations are integrating AI into customer support, software development, business intelligence, cybersecurity operations, healthcare workflows, financial services, and countless other domains.

As adoption accelerates, security strategies must evolve alongside it.

The next generation of AI security will not focus solely on protecting models from attack.

It will also focus on understanding how those models behave.

For decades, security professionals have operated under a simple assumption:

If you cannot observe a system, you cannot effectively secure it.

As AI becomes embedded in critical business processes, that principle remains unchanged.

The difference is that visibility must now extend beyond networks, applications, and identities.

It must reach into the decision-making processes of the models themselves.

And that is precisely where Explainable AI may become one of the most important security controls of the next decade.

References and Further Reading

Explainable Artificial Intelligence (XAI): What We Know and What Is Left to Attain Trustworthy Artificial Intelligence

Ali, S., Abuhmed, T., El-Sappagh, S., et al.
Information Fusion, Volume 99, 2023
https://doi.org/10.1016/j.inffus.2023.101805

Raw AI models are a fundamental security risk.

Ali-Funk — Mon, 01 Jun 2026 22:06:26 +0000

This is not my usual dev.to content BUT sometimes you just have to share what excites you.

The lecture clearly separates Pre-training from Post-training — and this distinction is critical for enterprises.

Pre-training basically teaches the model to predict the next word based on massive, unfiltered internet data. It has zero understanding of corporate policies, data protection, compliance or ethics.

Real business value and safety only emerge in Post-training.
Especially through techniques like RLHF (Reinforcement Learning from Human Feedback). This is where guardrails, alignment, and security controls are built.

As someone transitioning into System Integration with a strong cybersecurity background, this lecture reinforced my view:

AI alignment and governance are not just “nice-to-have” features.They are core components of modern IT security and risk management.

In a world where companies are rushing to integrate LLMs, weak post-training and missing governance will lead to massive data leaks, compliance violations, and security incidents. Solid infrastructure is essential, but secure and governed AI systems are what actually make AI usable in regulated environments.

We need to treat Generative AI as the ultimate infrastructure and security stress test.

What’s your take?

How is your organization handling AI governance and security in 2026?

Sources & Lecture:

Stanford CS229: Building Large Language Models
https://www.youtube.com/watch?v=9vM4p9NN0Ts

RLHF Documentation & Enterprise AI Security Frameworks

https://www.ibm.com/think/topics/rlhf

Supply Chain Attacks + Stale Credentials: Why This Combination Is So Dangerous in 2026

Ali-Funk — Sat, 23 May 2026 19:56:37 +0000

Recent incidents at GitHub and Grafana Labs highlight a painful truth in modern infrastructure: even strong perimeter defenses can fail completely when credential management is neglected.

What Happened ?

A supply chain attack through compromised TanStack npm packages led to the breach of over 3,800 internal GitHub repositories via a malicious VS Code extension. Shortly after, Grafana Labs disclosed that attackers stole their source code because a single GitHub token was missed during emergency rotation.

Two separate incidents. Same underlying problem.

The Core Lesson

Human memory is not a valid security strategy.
From my eight years of hands-on experience in IT infrastructure and administration, I’ve seen this pattern too many times. Teams invest heavily in firewalls, segmentation, and threat detection, yet basic credential hygiene.Especially secret rotation and least privilege — is often treated as an afterthought.

Why This Combination Is So Dangerous

When a supply chain attack meets stale credentials, the impact multiplies:

Attackers don’t need to crack passwords anymore. They simply abuse existing, trusted tokens.
A single missed token during rotation can give attackers long-term access to critical systems.
Compromised dependencies (like npm packages or VS Code extensions) act as silent entry points.

This is no longer theoretical. It’s the new normal in cloud-native and DevOps-heavy environments.

Practical Strategies for 2026

To defend against this threat, organizations need to move from reactive patching to architectural resilience:

Implement automated secret rotation

Credentials should expire by default. Automation removes human error from the equation.

Enforce strict least privilege
CI/CD tokens and service accounts should only have the minimum permissions required and nothing more.
Treat every third-party dependency as untrusted
Continuous scanning and monitoring of npm packages, VS Code extensions, and other tools must become standard.
Design systems that survive human error
Assume credentials will eventually leak.

Build architectures with strong segmentation, just-in-time access, and rapid detection of anomalous behavior.

Final Thoughts

In 2026, strong security is no longer just about blocking attacks from the outside.

It’s about designing systems that can survive inevitable compromises and human mistakes.

The combination of supply chain attacks and stale credentials is particularly dangerous because it exploits both trust in the ecosystem and gaps in our own processes.

How is your team handling secret rotation and supply chain security today?

Sources:

BleepingComputer:
GitHub confirms breach of 3,800 repos via malicious VS Code extension
https://www.bleepingcomputer.com/news/security/github-confirms-breach-of-3-800-repos-via-malicious-vscode-extension/

BleepingComputer: Grafana says stolen GitHub token let hackers steal codebase
https://www.bleepingcomputer.com/news/security/grafana-says-stolen-github-token-let-hackers-steal-codebase/

The Hacker News / Unit 42: TanStack npm supply chain attack analysis
https://unit42.paloaltonetworks.com/monitoring-npm-supply-chain-attacks/

The PCPJack Worm and the Death of Cloud Isolation

Ali-Funk — Fri, 08 May 2026 11:47:50 +0000

The discovery of the PCPJack malware framework in late April 2026 should serve as a wake up call for anyone responsible for cloud infrastructure security.

This is not just another piece of malware. It is a modular autonomous worm designed to spread across exposed cloud environments harvest credentials remove competing malware and establish persistent access. Researchers first noticed it when a hunting rule detected a script actively cleaning up traces of TeamPCP infections. That is a clear sign of competition between threat actors for control of compromised infrastructure.

The Real Architectural Failure

Attackers are no longer just breaching the perimeter. They are deploying malware that lives inside your environment moves laterally and maintains dominance.

The core problem is not the initial compromise. The real failure lies in weak internal isolation. When a single compromised workload can:

-Harvest credentials across the environment
-Move laterally between containers and cloud accounts
-Remove rival malware to maintain exclusive control
...your cloud architecture has a fundamental design flaw.

Modern cloud deployments often prioritize speed and developer convenience over proper segmentation least privilege access and east west traffic monitoring. The result is a flat overly trusting internal network where one breach can quickly escalate into full environment compromise.

What PCPJack Actually Teaches Us

PCPJack specifically targets cloud credentials developer environments container infrastructure and enterprise services. Its ability to clean up other malware shows a new level of sophistication. Criminal groups are now fighting each other for dominance over compromised infrastructure not just cashing out with ransomware.

This marks a shift in attacker behavior. From opportunistic breaches to persistent competitive infrastructure takeover.

The Zero Trust Reality Check

Traditional perimeter focused security is no longer sufficient. Organizations must assume breach and implement proper internal controls:

-Strict workload segmentation

-Least privilege access for every service and container

-Continuous monitoring of east west traffic

-Automated credential rotation and just in time access

-Behavioral anomaly detection inside the environment

If your architecture allows a single compromised container to map your internal network and harvest developer keys your security model is already outdated.

Final Thought

The PCPJack worm is not an isolated incident. It is a symptom of a deeper architectural problem. Cloud environments have grown too fast with convenience often prioritized over security fundamentals.

The question every security and infrastructure team should ask themselves today is:

Are we still securing the front door while leaving the internal network completely open?

The Silent Backdoor in Enterprise Security: Why Unmanaged OAuth Tokens Are the New High-Risk Vector

Ali-Funk — Tue, 05 May 2026 21:08:34 +0000

The rapid adoption of AI productivity tools is exposing a dangerous blind spot in enterprise security architecture. Organizations invest heavily in firewalls, SSO, and MFA not yet leave one of the most effective back doors wide open: persistent, unmanaged OAuth tokens.

The disconnect between technical execution and strategic risk management has never been clearer. We are building massive walls while leaving the vault unlocked.

The Core Problem

Every time an employee connects an AI tool, automation, or SaaS application to Google Workspace or Microsoft 365, a persistent OAuth token is created. These tokens:

Do not expire when employees leave the company
Do not reset when passwords change
Completely bypass traditional MFA
Often remain active for years with broad permissions

This is not a misconfiguration. This is how OAuth is designed to work — and most security programs were never built to handle it at the scale of Shadow AI.

Material Security’s 2026 research highlights the gap: 80% of security leaders consider unmanaged OAuth grants a critical or significant risk. Yet 45% of organizations still do nothing to monitor them at scale, while many others rely on manual spreadsheets and ad-hoc reviews.
Spreadsheets are not a security control. They are documentation of risk you don’t fully understand.

Real-World Proof: The Drift Incident

In August 2025, threat actors (UNC6395) stole OAuth refresh tokens from the Salesloft Drift integration. Using these legitimate tokens, they accessed Salesforce environments of over 700 organizations, including Cloudflare, PagerDuty, and others.

No passwords were cracked. No MFA was triggered. The attackers simply used already-approved, trusted integrations.

This incident demonstrates the new reality: a legitimate application today can become a serious weapon tomorrow.

What Effective OAuth Security Must Look Like

We need to move from point-in-time approval to continuous oversight with three key capabilities:

Behavioral Monitoring: Track what the application actually does (API calls, data volume, access patterns)

Blast Radius Assessment: Understand who approved the token and how much sensitive data it can reach.

Intelligent Response: Automatically revoke high-risk tokens and escalate ambiguous cases for human review

The Leadership Gap

The market no longer needs only people who can configure firewalls or write code. It needs leaders who can securely integrate powerful AI tools into enterprise architectures — without creating massive hidden risks.
True security leadership today means combining technical excellence with strategic governance: systems that continuously audit, assess, and respond to OAuth risk in real time.

Sources and Further Reading:

Material Security Research OAuth Grant Management Gap
https://material.security/resources/automating-oauth-grant-management-materials-research-shows-the-growing-gap-between-awareness-and-action

Palo Alto Networks Unit 42 Threat Brief Salesloft Drift OAuth Compromise
https://unit42.paloaltonetworks.com/threat-brief-compromised-salesforce-instances/

Google Threat Intelligence Widespread Data Theft via Salesloft Drift
https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift

OAuth 2.0 Security Best Current Practice IETF RFC
https://datatracker.ietf.org/doc/html/rfc9700

NIST Special Publication 800 63B Digital Identity Guidelines
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63B-4.pdf

The Abstraction of Cloud Engineering: How AI Agents Are Redefining Enterprise Architecture

Ali-Funk — Sat, 25 Apr 2026 12:35:39 +0000

Amazon Web Services is accelerating a structural shift in cloud engineering through prompt driven workflows and agent based automation capabilities. With platforms like Amazon Bedrock and its expanding architecture guidance AWS is moving toward a model where production ready environments can be generated with minimal manual configuration.

AWS provides reference architectures automated deployment patterns and prescriptive guidance through its official architecture center. Its startup platform further emphasizes rapid environment creation and scaling.

Real World Evidence: The Optimization for Zero Friction
To understand why this shifts the value of human talent we only need to look at how AI actually writes infrastructure code today. Industry research on AI generated code reveals a stark statistical reality. Analysis cited by Veracode demonstrates that up to 45 percent of AI generated code fails basic security tests and introduces on average 2.74 times more vulnerabilities than human written code from the same repositories.

Security analysis from Styra highlights a consistent pattern in AI generated Infrastructure as Code where models prioritize immediate functionality over secure configuration. This pattern is consistently observed in practice.

Consider a direct observed pattern frequently seen when deploying Kubernetes clusters through Amazon EKS. When prompted to generate a working cluster AI models often:

1.Expose the Kubernetes API endpoint publicly

2.Leave network policies completely undefined

3.Omit the private cluster configuration flag entirely

This behavior reflects the objective of the model. It optimizes for immediate usability. A public endpoint and unrestricted access ensure zero friction during the initial connection. The model optimizes for user gratification and immediate technical success. If the system works upon the first deployment the AI has fulfilled its direct positive instructions.

From a governance standpoint this optimization represents deferred risk. This friction removed by the AI is merely AMPLIFIED for the human operator who must later audit the architecture for regulatory compliance and secure segmentation.

Implicit Constraints: The Missing Attacker Path

A defining limitation of current AI models is their reliance on direct explicit commands. When a human prompts an agent to "Scaffold a microservice architecture" the AI executes exactly that positive command. However the prompt almost never includes the massive list of implicit negative constraints required by enterprise governance.

We do not prompt an AI with statements like "Build a public facing application but ensure it is not vulnerable to SQL injection cross site scripting or unauthorized access based on overly permissive IAM bindings". We operate under the assumption that an AI will handle these implicit constraints but it does not. It focuses entirely on technical capability. The attacker path was never included in the instructions.

From Infrastructure Execution to Governance

The constraint in cloud delivery is no longer infrastructure creation. Infrastructure as Code combined with AI driven generation has reduced build time from weeks to minutes. The primary constraint now moves to governance budget management and regulatory compliance.

When infrastructure can be generated autonomously misconfigurations scale at the same speed. The role of the enterprise architect must change accordingly. Value is no longer tied to manual configuration or boilerplate code. It is tied to defining the global guardrails validating generated systems and enforcing continuous compliance across all environments.

The New Skill Profile for Technical Talent

Configuration knowledge is no longer a durable differentiator. Provisioning compute networking and containers is increasingly automated. The differentiating skills required in the German and European markets are now:

System level reasoning across highly distributed architectures
Security and compliance evaluation against local standards
Complex integration into existing legacy enterprise environments
Risk management mid failure scenario

Knowing how to deploy a container is not a competitive skill. Understanding how an AI generated microservice architecture interacts with corporate identity systems data governance policies and rigid network boundaries is.

Enterprise Return on Investment: Speed Versus Integration Reality
For startups automation reduces time to market and initial costs allowing rapid experimentation and deployment of best practice architectures.

For large enterprises the return on investment equation is more complex. AI generates infrastructure but it also often introduces technical debt to achieve immediate functionality. The true enterprise cost is not in generating the initial setup but in integrating and governing it long term. This is exactly where technical account managers IT directors and cloud strategists create value by aligning the generated system with actual business and commercial constraints.

The Strategic Shift: From Reactive Auditing to Proactive Constraints
Cloud infrastructure is rapidly becoming a generated output rather than a manually constructed asset. This shift requires moving away from just reactive auditing of AI outputs toward proactive constraint enforcement. The ultimate goal for enterprise architecture is not just better auditing of what the AI built but building systems that enforce commercial and security requirements BEFORE the AI executes the prompt.

Organizations that adopt AI generated infrastructure without deep governance increase the likelihood of security incidents regulatory violations and uncontrolled cloud costs. Organizations that build strong control frameworks and governance structures will gain operational speed while maintaining control over security, compliance, and cost.

Sources

AWS Architecture Center: https://aws.amazon.com/architecture
AWS Startups Portal: https://aws.amazon.com/startups
Amazon Bedrock Overview: https://aws.amazon.com/bedrock
Styra AI Generated Infrastructure Analysis: https://www.styra.com/blog/ai-generated-infrastructure-as-code-the-good-the-bad-and-the-ugly/
Veracode AI Code Vulnerability Research: https://www.svenroth.ai/post/ai- generated-code-vulnerabilities-2-74x-4c9a7

Lets say my Manager wants Multi-Cloud (AWS + GCP) in 6 months here’s how I would respond and why

Ali-Funk — Thu, 02 Apr 2026 21:33:26 +0000

A contact on LinkedIn asked a question that every cloud architect eventually hears:

“Your manager says "We need to be Multi Cloud, AWS plus GCP. In 6 months."
You’re currently 100 % in AWS. Do you push back, agree, or propose a middle path? The reason behind the request matters more than the request itself.”

Here is exactly how I answered and why.

The Hidden Costs of the Multi-Cloud Trend

Transitioning to a Multi Cloud architecture is often sold as a strategic victory. When management sets a six month deadline to integrate GCP into an existing 100 % AWS environment, the first job of any engineer is to evaluate operational reality rather than marketing hype. Drawing on eight years of professional experience as a Solutions Architect, I consider this one of the most dangerous directives an engineering team can receive.

Questioning the Directive First

The very first step is always to clarify the objective. Is the company facing strict regulatory compliance that genuinely requires two clouds? Or is management simply afraid of "vendor lock in"? If the reasoning is
fear based rather than business-driven, the resulting architecture will be flawed from day one.

The one non negotiable exception is Mergers and Acquisitions. If your company just acquired an organization running natively on GCP, integrating that environment is a hard business mandate, not a trend.

Evaluating the True Costs

Data Egress

Cloud providers want your data to stay inside their ecosystem. Moving even moderate volumes of data between AWS and GCP triggers significant egress fees. The hyperscalers let data in for free but charge heavily to move it out. The network architecture required to bridge the two environments adds complexity and cost that is rarely budgeted.

Team Capacity

Forcing a single team to master both AWS and GCP is an engineering
anti pattern. The alternative , hiring a completely new team or launching extensive retraining programs , this cannot be done securely or effectively in just six months.

Architectural Coupling

The danger level of a six month timeline depends entirely on your compute layer.
If your AWS environment relies heavily on proprietary managed services like Lambda and DynamoDB, a GCP integration is an operational nightmare.

However, if your architecture is already heavily containerized using EKS and stateless microservices, dropping those workloads into Google Kubernetes Engine is significantly less complex.

Pipeline Fragmentation

Managing infrastructure state across two hyperscalers requires immense discipline. The cognitive load of preventing configuration drift while deploying to two different environments is almost never factored into management timelines. Securing two separate Identity and Access Management perimeters at the same time doubles the risk of a breach.

Here is a minimal Terraform example that illustrates the immediate fragmentation:

# AWS provider
provider "aws" {
region = "eu-west-1"
}

# GCP provider already doubling the cognitive load
provider "google" {
  project = "my-gcp-project"
  region  = "europe-west1"
}

# Two separate remote backends become mandatory
terraform {
backend "s3" { }      # AWS state
# GCP state needs its own backend GCS
}

A single terraform apply now touches two completely different ecosystems. State drift detection, IAM policies, and security scanning all become twice as complex.

When (and only when) Multi Cloud actually makes sense
In rare cases Multi Cloud is the right call: strict data-residency regulations that force workloads into specific GCP regions, a highly specialized service (such as BigQuery for massive analytics that has no cost-effective AWS equivalent), or a true disaster recovery strategy that demands geographic and provider diversity.

When those conditions are met, the safe middle path is not a big bang six month migration. Start with a narrow, non-critical "proof of concept" workload in GCP (e.g., a new analytics pipeline), keep the core platform in AWS, abstract common patterns with Terraform modules, and enforce strict cost and security gates before any production traffic moves.

Conclusion

Multi Cloud is not inherently bad, but rushing into it for the wrong reasons is expensive, risky, and almost always avoidable. The reason behind the request matters more than the request itself. Ask why first. Then protect the team and the architecture with data, not dogma.
Sources

AWS Data Transfer Out Pricing (to Internet / other clouds):

https://aws.amazon.com/ec2/pricing/on-demand/#Data_Transfer

Martin Fowler

“Don’t get locked up into avoiding lock-in” (Multi Cloud discussion):

https://martinfowler.com/articles/oss-lockin.html

HashiCorp
Workspace Best Practices for HCP Terraform (Multi Cloud state management):
https://developer.hashicorp.com/terraform/cloud-docs/workspaces/best-practices

DEV Community: Ali-Funk

Beyond the Playbook: Architecting Defenses Against Autonomous AI Threats

Beyond the Playbook: Architecting Defenses Against Autonomous AI Threats

From Static Playbooks to Autonomous Attackers

The Defensive Automation Gap

Architectural Implications for Enterprise Security

The Strategic Shift for Security Architects

Conclusion

Identity Is the New Perimeter: Why AI Agents Break Zero Trust

The Rise of Tool Calling

The New Attack Surface

Why Traditional Zero Trust Falls Short

How to Actually Secure AI Agents

Use Short-Lived Credentials Only

Apply True Least Privilege

Eliminate Static API Keys

Aggressively Isolate Agent Workflows

Continuously Monitor Agent Behavior

The New Reality of Identity Security

Non-Human Identities: The Silent Attack Surface No One Is Monitoring

Defining the Non-Human Identity Landscape

Why Attackers Are Targeting NHIs

Building a Machine Identity Security Strategy

The New Security Frontier

Building a Serverless Security Monitoring Pipeline for AWS Bedrock

Shadow AI and OAuth: Why the OAuth Token Is Now Your Biggest Blind Spot

The Perimeter Has Moved

The Core Problem: Delegated Trust and Non-Human Identities

The Anatomy of an AI OAuth Exploit

Real-World Precedent: The Drift/Salesloft Attack

Why Traditional IAM Breaks Here

Hardening the Identity Perimeter

The New Perimeter Is Identity

References

Explainable AI: The Missing Security Layer in Enterprise Cloud Deployments

The Black Box Problem

Why Traditional Security Controls Are Not Enough

Explainability as Security Telemetry

Security, Governance, and Regulatory Pressure

Explainability Does Not Mean Perfect Understanding

The Future of AI Security

References and Further Reading

Explainable Artificial Intelligence (XAI): What We Know and What Is Left to Attain Trustworthy Artificial Intelligence

Towards Monosemanticity: Decomposing Language Models With Dictionary Learning

Explainable AI (XAI)

Explainable AI Documentation

AI Risk Management Framework (AI RMF 1.0)

OWASP Top 10 for Large Language Model Applications

EU Artificial Intelligence Act

Raw AI models are a fundamental security risk.

Supply Chain Attacks + Stale Credentials: Why This Combination Is So Dangerous in 2026

The PCPJack Worm and the Death of Cloud Isolation

The Silent Backdoor in Enterprise Security: Why Unmanaged OAuth Tokens Are the New High-Risk Vector

The Abstraction of Cloud Engineering: How AI Agents Are Redefining Enterprise Architecture

Lets say my Manager wants Multi-Cloud (AWS + GCP) in 6 months here’s how I would respond and why