DEV Community: Ali-Funk

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

I highly recommend for you all to see theses views on comments in your code. Great perspective!

Ali-Funk — Tue, 31 Mar 2026 17:14:38 +0000

Tual Maxime (@filozofer)

Mar 22

I was asked to delete my comments before committing

#git #productivity #developer #ai

Comments 22

5 min read

The AI Rebound Effect and the Transition to Systems Architecture

Ali-Funk — Tue, 31 Mar 2026 07:12:26 +0000

The reaction to the recent Claude AI outage reveals a fundamental misunderstanding of how developers should interact with artificial intelligence.

Reports of developers feeling entirely unable to work without their AI assistant point to a dangerous trend of „deskilling“.

John Nosta accurately describes this as the „AI rebound effect“, where improved performance masks a rapidly declining foundational ability.

If an engineer relies so heavily on a probabilistic model that they cannot function when it goes offline, they are using the tool incorrectly.
One developer on Reddit described it as : "I wrote code like a caveman"

The future of software engineering requires us to elevate our skills, not abandon them. Instead of focusing purely on syntax generation and accepting the first output a model provides, I find that engineers should or even must transition into the role of systems architects.

By mastering agentic workflows and deterministic execution, we shift our cognitive load from writing boilerplate code to designing complex and secure infrastructure.

The AI handles the syntax, but the human must control the logic (or at least the human should be in control), the security constraints, and the integration points.

Letting your core skills regress is a choice.

The alternative is to step up, utilize spec driven development, and master the architecture that governs the AI.

Sources:

Business Insider: AI deskilling impact on worker skills and productivity
https://www.businessinsider.com/ai-deskilling-impact-on-worker-skills-productivity-2026-3
Psychology Today: The AI Rebound Effect and Cognitive Decline
https://www.psychologytoday.com/us/blog/the-digital-self/202508/ai-rebound-the-paradoxical-drop-after-the-ai-lift
Hyper AI: The Great AI Deskilling Trend https://hyper.ai/en/stories/93549dd29c8a15321052bf0d1d71a5e4

The European Commission AWS Breach and the Failure of Paper Security

Ali-Funk — Fri, 27 Mar 2026 13:33:07 +0000

The European Commission, the executive body of the European Union, is currently investigating a security breach of its Amazon Web Services infrastructure.

According to a report published today by Bleeping Computer, a threat actor gained access to at least one AWS account used to manage the Commission's cloud environment. Although the incident was detected quickly, the breach demonstrates a critical reality:
administrative checklists and compliance frameworks fail where deterministic architecture is missing. If the most heavily regulated entity in Europe can suffer an AWS breach, paper security is proven ineffective against real-world threat actors.

The Misunderstood Shared Responsibility Model

When an enterprise-level breach occurs on AWS, the failure is almost never on the side of the provider. The AWS Shared Responsibility Model is explicit. Amazon secures the facility, the compute hardware, the hypervisor, and the underlying global network. The customer is entirely responsible for securing everything in the cloud: the configuration, the data, the applications, and the identity perimeter.

AWS makes this distinction crystal clear: Amazon secures the cloud, while the customer secures what is inside the cloud. You cannot audit your way to a secure configuration. Threat actors do not read your ISO 27001 documentation. They scan for misconfigured S3 buckets, overly permissive IAM roles, exposed access keys, and configuration drift.

The moment you rely on manual changes in the AWS Management Console, you introduce human error. In a cloud environment, that single human error can scale instantly into a structural compromise.

Deterministic Security through Infrastructure as Code

The only reliable way to prevent cloud takeovers is to remove manual intervention entirely. Security must be engineered directly into the deployment pipeline using Infrastructure as Code.

By defining your entire AWS environment with Terraform, you transform abstract security policies into mathematical certainty. Every IAM policy, every private subnet, every security group rule, and every encryption setting is declared in code, version-controlled, peer-reviewed, and applied through automated pipelines.

The Terraform state file becomes the single source of truth for your infrastructure. If an engineer attempts to manually alter a configuration in the AWS console, the next Terraform run will detect the drift and revert the environment back to its secure baseline.

This mechanism directly prevents the exact type of configuration drift that attackers exploit to gain and expand their foothold.

Here is a minimal example that enforces least privilege and blocks dangerous actions attackers commonly abuse:

# Enforce least-privilege IAM with no long-lived access keys
resource "aws_iam_role" "app_role" {
  name = "ec2-app-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect    = "Allow"
      Principal = { Service = "ec2.amazonaws.com" }
      Action    = "sts:AssumeRole"
    }]
  })
}

resource "aws_iam_policy" "least_privilege" {
  name = "least-privilege-policy"

A single terraform apply now guarantees these boundaries cannot be weakened by console clicks or emergency fixes.

Enforcing the Identity Perimeter

Traditional network boundaries are obsolete in cloud environments. Identity is the only true perimeter left.
To prevent the unauthorized access seen in the European Commission breach, strict Identity and Access Management must be enforced at the API level. This means abandoning static, long-lived access keys in favor of temporary credentials generated through AWS IAM Identity Center or IAM Roles Anywhere. Every workload, every autonomous agent, and every service must operate under the strict principle of least privilege.
If an attacker compromises a single service, well-defined execution boundaries must prevent lateral movement into sensitive databases or escalation to higher-privilege administrative roles.

Conclusion

Compliance is a byproduct of good engineering, not the other way around. Building a resilient AWS environment requires deep operational experience and a genuine commitment to deterministic architecture.

We must stop treating security as an administrative burden and start treating it as a "core engineering discipline."

In my view "Paper policies" do not stop breaches. Code does.

Sources

Bleeping Computer Report on the European Commission AWS Breach

(March 27, 2026):

https://www.bleepingcomputer.com/news/security/european-commission-investigating-breach-after-amazon-cloud-hack/

AWS Shared Responsibility Model:

https://aws.amazon.com/shared-responsibility-model/

HashiCorp Terraform State Management:

https://developer.hashicorp.com/terraform/language/state

The End of the Demo Phase: Securing AI Infrastructure in the Enterprise

Ali-Funk — Sat, 21 Mar 2026 11:22:32 +0000

The Market Reality

We are officially moving past the demo phase of artificial intelligence. The new NVIDIA certification framework correctly categorizes AI Networking and AI Operations as distinct professional tracks. Enterprise value is no longer created by chatting with a generative model. It is created by integrating these systems into highly secure cloud environments.

The Architectural Divide

The industry is currently splitting into two definitive paths. You are either building intelligence or you are building infrastructure. While the application track focuses on probabilistic generative models, the infrastructure track demands absolute deterministic control. The application track is rapidly fragmenting into countless new tools, while the infrastructure track relies on the permanent constants of physical networks, compute clusters, and Zero Trust architecture.

The Security Mandate

You can design the most advanced multimodal system in the world. If you deploy it into a Virtual Private Cloud with broad subnet allowances and weak ingress rules, you have failed the enterprise.

While rapid iteration is valuable in R&D, production environments demand deterministic controls. Probabilistic systems guess and iterate — when they are allowed to iterate across an unsecured network, they become a critical vulnerability. A broad network configuration is a lazy engineering practice that breaks isolation and expands the blast radius.

Here’s the difference in practice (Terraform):

[FAIL] Demo era configuration
ingress {
from_port   = 443
to_port     = 443
protocol    = "tcp"
cidr_blocks = ["0.0.0.0/0"]  # This opens up to the entire world!
}
[PASS] Production era Zero Trust configuration
ingress {
description      = "HTTPS from internal networks"
from_port        = 443
to_port          = 443
protocol         = "tcp"
cidr_blocks      = ["10.0.0.0/16"]
security_groups  = [aws_security_group.app.id] # Limit access to a specific application security group
}

The Operational Execution

My operational reality is securing this foundation. Bringing eight years of operational IT experience into my current AWS Solutions Architect training, I understand that data scientists need a highly restricted environment: VPC endpoints only, no public subnets, IAM roles with least-privilege access for SageMaker or Bedrock, network ACLs combined with security groups, and private model registries.

This aligns perfectly with my direct progression toward a Master of Business Administration in IT Security and Compliance. Securing compute clusters and enforcing Zero Trust network boundaries is the only way to move intelligent systems from isolated tests into production. This requires strict Terraform execution and absolute adherence to compliance standards.

The future of enterprise scale belongs to those who build the secure boundaries.

Sources

1.NVIDIA Deep Learning Institute Certification Framework:
https://www.nvidia.com/en-us/training/certification/

2.AWS Security Best Practices for Machine Learning:
https://docs.aws.amazon.com/sagemaker/latest/dg/security.html

3.NIST Artificial Intelligence Risk Management Framework:
https://www.nist.gov/itl/ai-risk-management-framework

4.HashiCorp Terraform AWS Provider Documentation:
https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/security_group

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

Zero Trust Architecture for AI Runtime Execution

Ali-Funk — Tue, 17 Mar 2026 22:03:04 +0000

The introduction of the Bedrock AgentCore Runtime Shell Command elevates large language models from text generators to active system participants. This capability demands a strict zero trust architecture.

Enterprise operations require predictability. When deploying an autonomous shell, the infrastructure must enforce a zero trust baseline. Giving a probabilistic model direct interaction with an operational environment is a massive paradigm shift. We can no longer rely on prompt engineering to secure an enterprise environment. Trusting a generative model to obey natural language constraints is a structural vulnerability. Instead, we must apply strict deterministic limits.

Here is how we build the architecture for an autonomous shell:

Network Isolation
The execution environment must be entirely sealed. Place the Bedrock agent runtime in a dedicated Virtual Private Cloud with no inbound internet access. Outbound connections must be explicitly allowed to approved endpoints only.

Identity and Access Management
The role assumed by the agent must have a strict permissions boundary. It should never have the ability to alter its own permissions or create new policy versions. Limit the blast radius to the exact resources required for the task.

Immutable Logging
Every system command generated and executed by the shell must be recorded. Send these logs to an isolated storage bucket where the agent has zero write access. You need a verifiable audit trail of every automated action.

Security is not optional. We MUST build environments that dictate the rules to the AI. We MUST treat the autonomous shell exactly like an unverified external entity. Security is established by deterministic infrastructure rules, never by generative models.

Sources:

https://aws.amazon.com/about-aws/whats-new/2026/03/bedrock-agentcore-runtime-shell-command/

https://docs.aws.amazon.com/bedrock/latest/userguide/security-iam.html

https://aws.amazon.com/architecture/security-identity-compliance/

Why End-to-End Encryption Cannot Protect Infrastructure Metadata

Ali-Funk — Mon, 09 Mar 2026 20:30:31 +0000

The recent incident involving Proton and the FBI is not a technical failure of encryption. It is a harsh reminder of a fundamental architectural truth:

end-to-end encryption protects the payload, but network infrastructure inevitably generates metadata.

When enterprise architects or privacy advocates confuse encrypted storage with "absolute" anonymity, they create a massive vulnerability in their threat model, at least that´s my view.

At its core, end-to-end encryption ensures that the content of a message remains cryptographically sealed between the sender and the recipient. The service provider cannot read the payload.

However, delivering that payload requires routing. It requires session tokens, account creation timestamps, payment gateways, and recovery email addresses. This operational "exhaust" is the metadata and that metadata can be analyzed.

When legal compliance frameworks and cross-border assistance treaties are activated, authorities do not need to break the AES or RSA encryption of the message content.

What do they have to do instead to get around it ?

They simply target the metadata. A recovery email address linked to a different provider or a logged IP address from a specific session is often more than enough to establish identity.

The industry is finally beginning to recognize this vulnerability at the network layer. For example, Mullvad VPN recently integrated DAITA (Defense against AI-guided Traffic Analysis) into their infrastructure.

Because modern AI can analyze the size and timing of encrypted packets to accurately infer user activity, DAITA pads all data packets to a constant size and injects random "dummy" traffic into the tunnel.
This feature is a direct architectural response to the fact that payload encryption is no longer enough. The battleground has entirely shifted to obscuring the operational exhaust.

However, while tools like DAITA protect real-time traffic analysis from ISPs or data brokers, they do not solve the static identity problem.

After eight years in operational IT, the most common architectural flaw I observe is the assumption that a secure application automatically provides a secure environment. But the assumption is what I see as a mindset problem.

If you deploy a highly encrypted service but fail to govern the underlying identity verification mechanisms or account recovery paths, you have only shifted the vulnerability.

Trusting a third-party service provider ultimately means trusting THEIR local legal jurisdiction and their logging mechanisms. Marketing claims about safe haven data centers do not override international legal cooperation.

If your threat model requires absolute operational anonymity, relying on a _public _ SaaS provider is architecturally insufficient, regardless of how "strong" their encryption is. You must govern the ENTIRE DATA LIFECYCLE, from the physical network routing up to the application layer.

That is very expensive. That is why only the so-called "Hyperscalers" Amazon Web Services, Google Cloud and Microsoft Azure can do it.

To truly understand this vulnerability, we must visualize the network journey. The following architecture diagram maps a standard secure connection. Notice how the core payload is protected, yet the operational exhaust like DNS requests, routing IP addresses, and session logs remains fully exposed at multiple infrastructure layers.

The Visual Proof: Payload vs. Metadata Exhaust

This reality completely dismantles the illusion that small-scale operators can realistically govern the entire data lifecycle without relying on external infrastructure. It proves that true digital sovereignty is a financial issue, not just a technical one.

Everything else is just an illusion of privacy.

Sources:

Proton: FBI user identification shakes Swiss data protection
https://www.heise.de/en/news/Proton-FBI-user-identification-shakes-Swiss-data-protection-11203086.html
Proton Legal and Privacy Policy
https://proton.me/legal/privacy
Mullvad VPN: Introducing Defense against AI-guided Traffic Analysis (DAITA)
https://mullvad.net/en/blog/introducing-defense-against-ai-guided-traffic-analysis-daita
Electronic Frontier Foundation: The Problem with Metadata
https://www.eff.org/deeplinks/2013/06/why-metadata-matters

Architecting Zero Trust for Autonomous Agents

Ali-Funk — Sat, 07 Mar 2026 22:03:43 +0000

Network Segregation and Identity Boundaries

Integrating autonomous systems and agentic orchestration fundamentally changes enterprise cloud architecture. Granting software the ability to execute dynamic decisions requires "absolute"governance.

When you deploy these agents into production, you are introducing a highly capable entity inside your perimeter. Securing this new operational paradigm requires a dual approach: strict network isolation at the infrastructure layer and granular execution boundaries at the identity layer.

Deploying autonomous agents into a flat network is a critical vulnerability. If an agent is compromised or hallucinates an incorrect operational path, the blast radius must be physically contained. Utilizing AWS Transit Gateway allows us to architect strict routing domains. The agents are placed in isolated virtual private clouds that cannot communicate directly with core enterprise workloads. All traffic is forced through centralized security inspection hubs. This ensures that even if an agent attempts unauthorized lateral movement, the underlying network architecture mathematically blocks the routing.

However, network isolation is only half the architecture. The agent must also be restricted in what AWS APIs it can call. Implementing IAM Permissions Boundaries ensures that an agent cannot escalate its own privileges or modify its own guardrails. By combining strict identity policies with resource tags, we ensure the agent only interacts with explicitly approved data sets and services. This creates a hard ceiling on the maximum possible permissions the agent can assume, regardless of the role it is executing.

True architectural leverage comes from enabling advanced capabilities while limiting their risk. Sounds obvious but it isn´t.

Combining firstly "Transit Gateway routing isolation" with secondly
"IAM permissions boundaries" provides the exact governance required to *safely * integrate autonomous orchestration into modern environments.

You build the infrastructure so the software cannot break the rules.

Sounds abstract in an article but if you get this wrong in the real world the consequences are news worthy.

Here are some real world examples:

The Register: Vibe coding service Replit deleted production database
https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/

The Guardian: Amazon cloud hit by outages caused by AI tools
https://www.theguardian.com/technology/2026/feb/20/amazon-cloud-outages-ai-tools-amazon-web-services-aws

Sources:

AWS Transit Gateway Architecture
https://aws.amazon.com/transitgateway/
AWS IAM Permissions Boundaries
https://aws.amazon.com/iam/
AWS Cloud Security
https://aws.amazon.com/security/

Why Bare Metal Nostalgia is Dead and Cloud Governance is the New Sovereignty

Ali-Funk — Sun, 01 Mar 2026 23:21:38 +0000

The romantic idea of the isolated local server is dead. Let us look at the absolute reality of enterprise architecture in 2026. The cloud won the infrastructure war. Even the loudest advocates for European digital sovereignty, like the Schwarz Group with their STACKIT initiative, recently realized they had to form a massive strategic partnership with Google Cloud to actually deliver modern services. Retreating entirely to local hardware is operational suicide for any globally scaling business.

But acknowledging that the hyperscalers won does not mean we have to surrender our architecture to them.

Right now, cloud providers are using their market dominance to fund their massive artificial intelligence bubble. They are raising compute prices and forcing their enterprise customers to foot the bill. Companies that built their entire infrastructure using proprietary click operations within a single provider dashboard are now trapped in a devastating financial lock in. They are bleeding cash with absolutely zero leverage to negotiate.

The immediate reaction from traditional IT departments is panic. They want to retreat. They want to buy bare metal, rack physical servers in basements, and hire traditional system integrators to plug in cables.
But the traditional system integrator is an outdated concept ( I know because I am re-training to get official certified as one). It is a piece of paper designed to bypass human resources filters, not a strategy for building modern, resilient global architecture.
For that, at least in my view, you need to become a Cloud Architect.

True digital sovereignty in 2026 does not mean owning the physical metal. It means owning the abstraction layer.

Real power lies in infrastructure as code. If you use tools like Terraform to define your entire environment via the command line interface, you own the architectural blueprint. You utilize the hyperscaler, but the hyperscaler does not own you. Your enterprise architecture is not "held hostage" inside their proprietary menus.

This is where infrastructure as code transforms from a technical practice into a financial weapon. I call it "Architectural Leverage."

When your entire system is abstracted into code, you hold the ultimate negotiating power. If a cloud provider suddenly doubles their compute pricing to fund their algorithmic models, you do not panic. You do not beg your account manager for a discount. You simply change the provider variables in your codebase and deploy your environment somewhere else.
At least you should.
You use portability to keep the cloud providers in check and your costs low.

The industry does not need traditional network administrators anymore. It desperately needs modern cloud governance engineers. Over my eight years of professional experience, I have seen the cycles of outsourcing and the inevitable structural failures it causes. Enterprises now require professionals who can execute three core directives:

1.Design abstracted deployments

2.Aggressively audit billing cycles

3.Ensure structural flexibility to shift workloads without rebuilding
the foundation

Digital sovereignty is no longer about avoiding the cloud. It is about using strict code governance to dictate exactly where the enterprise spends its money.

Sources:

1.Basecamp The Big Cloud Exit FAQ
https://world.hey.com/dhh/the-big-cloud-exit-faq-20274010

2.Andreessen Horowitz The Cost of Cloud a Trillion Dollar Paradox
https://a16z.com/2021/05/27/cost-of-cloud-paradox/

3.CUDO Compute Why AI teams need cloud infrastructure without vendor lock ins
https://www.cudocompute.com/blog/why-ai-teams-need-cloud-infrastructure-without-vendor-lock-ins

4.Luminis Digital Sovereignty and the Public Cloud Navigating Azure in a European Context
https://www.luminis.eu/blog/digital-sovereignty-and-the-public-cloud-navigating-azure-in-a-european-ccontext/