Your AI Agent Can Be Compromised Before It Runs Your Code

Introduction: Your Code Can Be Secure While Your Application Is Not#

Imagine spending weeks building an AI agent.

You validate user input, protect your API endpoints, implement authentication, review your dependencies, and write tests. The application passes your security checks, and you deploy it to production.

Then a security incident exposes your environment.

The problem was not necessarily in the code you wrote. It may have been in the runtime executing that code, a dependency you installed, or the build pipeline that produced the artifact you deployed.

This is the uncomfortable reality of software supply-chain security.

Your application is only one component in a much larger system. Its security also depends on the tools, libraries, runtimes, containers, build processes, and credentials surrounding it.

This problem becomes particularly important when building AI infrastructure.

AI agents and model gateways may have access to API keys, cloud credentials, source repositories, databases, internal services, and tools that can execute commands. A compromised component in that environment can put much more than one application at risk.

Two incidents reported in October 2026 illustrate the problem from different directions.

On October 21, the PHP project published security updates for two critical vulnerabilities that could allow unauthenticated remote code execution on affected systems. On the same date, the LiteLLM 1.107.0 release was compromised, with malicious artifacts distributed through package and container registries. The compromised Python package could execute code during interpreter initialization without the application explicitly importing LiteLLM.

These incidents involve different technical failures, but they point toward the same engineering lesson:

Securing an application requires verifying the entire path from source code to the software running in production.

Let's examine what happened, why traditional dependency management is not enough, and how to build safer AI infrastructure.

1. The Real Attack Surface Is Larger Than Your Application#

A typical web application might look simple from the developer's perspective:

1. A request reaches the server.
2. The application validates the input.
3. Business logic processes the request.
4. The application accesses a database or external service.
5. The response returns to the user.

But this view hides the layers beneath the application.

A production service may depend on:

• The operating system and system libraries.
• The programming language runtime.
• Third-party packages.
• Package registries.
• Container base images.
• Build tools and CI/CD workflows.
• Deployment credentials.
• Secret-management systems.
• Cloud infrastructure and identity permissions.
• Monitoring and incident-response systems.

A weakness in any of these layers can undermine the security of the application above it.

For example, input validation is useful when protecting against malicious requests. But it cannot reliably compensate for a critical memory-safety vulnerability in the runtime that processes those requests.

Similarly, reviewing a Python library's source code does not prove that the package installed on a production server contains exactly that source code.

These are different security boundaries, and each needs its own controls.

Why AI infrastructure deserves extra attention#

Consider a typical AI application:

                  User
                   |
                   v
             Web Application
                   |
                   v
               AI Agent
                   |
          +--------+--------+
          |        |        |
          v        v        v
        LLM API  Database  Tools
                            |
                    +-------+-------+
                    |       |       |
                    v       v       v
                  Shell   Browser  Repository

Now add the infrastructure that supports it:

AI Application
      |
      +-- Language Runtime
      |
      +-- Python / JavaScript Dependencies
      |
      +-- LLM Gateway
      |
      +-- Agent Execution Environment
      |
      +-- Container Images
      |
      +-- CI/CD Pipeline
      |
      +-- Cloud Credentials
      |
      +-- Deployment Infrastructure

A compromise in one of these layers can expose resources that the application was trusted to access.

For example, an agent runner may possess credentials that allow it to read a private repository or call a paid model API. A build pipeline may have permission to publish container images. An LLM gateway may hold credentials for multiple providers.

The consequences of a compromised dependency therefore depend not only on what the dependency does, but also on the privileges of the environment in which it executes.

This is why AI security must include infrastructure security.

2. Case One: Critical PHP Vulnerabilities Can Undermine Application Defenses#

On October 21, 2026, the PHP project published security updates addressing two critical vulnerabilities:

• CVE-2026-109618: A vulnerability involving out-of-memory handling and partially initialized internal request data.
• CVE-2026-109619: A vulnerability involving stale internal state and memory that had already been freed.

The PHP security advisory states that the vulnerabilities could allow unauthenticated remote code execution on affected installations. The project urged users to update immediately.

The significance is not limited to applications that contain obviously unsafe code.

These vulnerabilities affect the runtime itself, the software responsible for executing PHP applications.

How can a runtime vulnerability affect an application?#

A simplified request-processing flow looks like this:

Incoming HTTP Request
          |
          v
      Web Server
          |
          v
      PHP Runtime
          |
          v
   Application Code
          |
          v
      Database

The application depends on the runtime to process requests safely.

If an attacker can exploit a runtime vulnerability before the application completes its normal processing, application-level protections may not be enough to prevent the underlying problem.

This does not mean that every PHP application was successfully exploited. Exposure depends on the affected version, configuration, deployment architecture, and other conditions.

It does mean that application developers cannot assume their code is safe merely because they have implemented good validation and authentication.

Which PHP versions were affected?#

The official PHP advisory identifies the following patched releases:

The advisory also identifies older PHP versions that do not receive upstream security fixes. If you operate an older, unsupported branch, moving to a supported version is an important part of remediation. Confirm the current advisory and your hosting provider's guidance before changing a production environment.

Official reference: PHP 2026 security advisories

What should engineering teams do?#

The response should be more comprehensive than changing a version number in a configuration file.

A practical process includes:

1. Inventory deployed runtimes. Identify every service that uses PHP, including production websites, staging environments, containers, background workers, and less frequently maintained applications.

2. Identify affected versions. Check the runtime actually executing in production, not only the version specified in a local development environment.

3. Apply the appropriate security update. Coordinate with the hosting provider or platform team where the runtime is managed externally.

4. Rebuild and redeploy. Ensure the patched runtime is included in the actual deployment artifact.

5. Verify the running version. Check the deployed environment after the rollout. A successful build does not prove that every production instance has been updated.

6. Investigate suspicious activity when warranted. If a service was exposed while vulnerable, review relevant logs, alerts, and other available evidence. Patching addresses the vulnerability but does not, by itself, establish whether an earlier compromise occurred.

The central lesson is straightforward: security controls at the application layer cannot replace security maintenance at the runtime layer.

3. Case Two: The LiteLLM Supply-Chain Compromise#

The second incident demonstrates a different failure mode.

LiteLLM is an open-source project used to connect applications to large language model providers through a common interface and gateway.

On October 21, 2026, a compromised release of LiteLLM 1.107.0 was published to PyPI and distributed through container registries.

According to LiteLLM's incident report, the affected PyPI package was available for approximately two hours. Several container tags also pointed to compromised images during a limited period. The official 1.107.0 source tag did not contain the malicious files, and the compromised artifacts had been built from an attacker-controlled repository.

Microsoft's investigation described malicious components capable of executing during Python interpreter initialization. This meant that starting Python in an affected environment could be sufficient to trigger execution, even when the application did not explicitly import LiteLLM.

The incident illustrates a critical distinction:

The source code a developer reviews and the artifact a production environment installs are not necessarily the same thing.

How can a trusted release become malicious?#

A simplified software release process looks like this:

Source Repository
       |
       v
   Build Workflow
       |
       v
   Package Build
       |
       v
 Package Registry
       |
       v
  Application Install
       |
       v
  Production Runtime

Each transition is a trust boundary.

A developer may review the repository and approve a change. The build workflow then retrieves source code, creates a package, and publishes it to a registry. A production environment later downloads and executes that package.

If an attacker compromises a privileged account or build workflow, the published artifact may no longer correspond to the source revision the developer reviewed.

This is why checking only the repository is insufficient.

What made the LiteLLM incident especially concerning?#

The reported incident combined several risks:

• Compromised release and publication processes.
• Malicious artifacts distributed through trusted registries.
• Python startup behavior that could execute code before the application imported the affected library.
• An environment where credentials and other sensitive data could be accessible to running processes.

Microsoft reported that the compromised components targeted credentials and authentication material across developer tools, AI applications, cloud environments, and infrastructure.

The exact impact depends on whether an affected artifact was installed or executed and what access the environment possessed.

The broader security lesson is that a dependency compromise can become a credential compromise when the dependency executes in an environment with valuable privileges.

Why does this matter for AI agents?#

AI systems frequently rely on packages that connect models to databases, tools, APIs, and execution environments.

An AI agent may run inside an environment that has permission to:

• Read private source repositories.
• Call external model providers.
• Access application databases.
• Execute code or shell commands.
• Retrieve secrets from environment variables.
• Publish artifacts through CI/CD.
• Access internal services.

If a malicious component executes in that environment, the consequences may extend beyond the component itself.

The risk is not exclusive to AI software. Any application with sensitive credentials can be affected by a supply-chain compromise.

However, AI infrastructure often combines multiple external integrations and privileged tools, making it especially important to restrict what each component can access.

What should affected teams do?#

If you believe your environment installed or executed an affected artifact, follow the current vendor and security-advisory guidance.

At a high level, the response should include:

1. Identify whether the affected package or container artifact was installed or executed.
2. Isolate affected systems where appropriate to prevent further access.
3. Preserve relevant logs and investigation evidence.
4. Rotate credentials that may have been exposed, including applicable API tokens and cloud credentials.
5. Rebuild from verified artifacts and trusted sources.
6. Review repository, cloud, CI/CD, and service activity for evidence of unauthorized access.
7. Restore production only after verifying the replacement environment and its credentials.

Removing the affected package is not necessarily enough. If the package executed while credentials were accessible, those credentials may no longer be trustworthy.

For current incident details and affected artifact information, consult the official LiteLLM incident report and Microsoft's security analysis.

4. Why Dependency Pinning Is Not Enough#

Dependency pinning is an important security practice.

Instead of allowing a project to install whichever package version happens to be the latest, a dependency manifest or lockfile specifies the versions that should be installed.

For example, a Python project might maintain a lockfile containing an exact version of a library and its resolved dependencies.

This improves reproducibility and makes it easier to investigate unexpected changes.

But pinning answers only one question:

Which version are we asking the package manager to install?

It does not automatically answer these other questions:

• Is the package authentic?
• Was it built from the expected source revision?
• Has the package registry been compromised?
• Does the installed artifact match the artifact that was reviewed?
• Are the build tools and workflow trustworthy?
• What privileges will the package have when it executes?

The LiteLLM incident demonstrates why those questions matter. A specific version can be pinned while the artifact associated with that version is compromised.

Pinning is therefore one layer of defense, not a complete supply-chain security strategy.

Four different controls solve four different problems#

These controls work best together.

For example, a CI pipeline can pin a dependency, verify its hash against a trusted manifest, validate available provenance information, and run the build in an isolated environment with limited credentials.

Each control addresses a different failure mode.

5. What Is Artifact Provenance, and Why Should Developers Care?#

Artifact provenance is information about where a software artifact came from and how it was produced.

Depending on the build system, provenance may identify:

• The source repository.
• The source revision or commit.
• The build workflow.
• The builder identity.
• The build process and parameters.
• The resulting artifact's digest.

This information helps a deployment system evaluate whether an artifact came from an expected and trusted process.

Imagine that your team builds a container image from a reviewed commit.

You expect the final image to have a verifiable connection to that commit and to an approved CI workflow.

If an image appears from an unexpected repository, an unapproved builder, or a workflow that did not meet your policy, the deployment process should flag it.

The objective is not to assume that every artifact is trustworthy because it exists in an official registry. The objective is to establish evidence about the artifact's origin.

Provenance is not the same as a checksum#

A checksum can tell you whether the bytes you downloaded match an expected digest.

But where did that expected digest come from?

If an attacker controls both the artifact and the place where its digest is published, a matching checksum alone does not establish that the artifact is trustworthy.

Provenance can add information about the build process and the identity of the builder.

Even then, provenance is not a universal guarantee of safety. A legitimate build can produce vulnerable software, and a trusted source can contain malicious changes.

The strongest approach combines source review, trusted build infrastructure, artifact integrity checks, provenance verification, and runtime controls.

A practical release policy#

For a production service, define an explicit policy for what may be deployed.

For example:

• Dependencies must be declared in a reviewed manifest or lockfile.
• Critical artifacts must match expected digests.
• Where available, provenance must identify an approved repository and builder.
• Build workflows must use restricted permissions.
• Production images must be traceable to a reviewed source revision.
• Unexpected artifacts must be rejected rather than silently accepted.
• Release records must be retained for later investigation.

This turns supply-chain security from a collection of manual checks into a repeatable release process.

6. AI Agents Need Least-Privilege Credentials#

AI agents introduce another important consideration: what happens when an agent has more access than its task requires?

Consider a coding agent that needs to inspect a repository and propose a change.

It might genuinely need read access to the repository. It may also need permission to create a branch or submit a pull request.

But does it need unrestricted access to production cloud credentials?

Does it need permission to publish a release directly?

Does every task need access to all environment variables available to the runner?

Usually, the answer should be no.

The principle of least privilege says that each component should receive only the permissions necessary to perform its intended job.

A risky agent architecture#

AI Agent
   |
   +-- Full repository access
   |
   +-- Production API keys
   |
   +-- Cloud administrator credentials
   |
   +-- Database administrator access
   |
   +-- Unrestricted shell
   |
   +-- Direct deployment permissions

This architecture creates a large potential blast radius.

If the agent, one of its dependencies, or its execution environment is compromised, a single failure may expose many unrelated systems.

A safer architecture#

                 AI Agent
                    |
                    v
             Isolated Runner
                    |
          +---------+---------+
          |         |         |
          v         v         v
      Read-only   Test      Scoped
      Repository  Tools     Tokens
          |         |         |
          +---------+---------+
                    |
                    v
              Human Review
                    |
                    v
             Approved Release

This approach limits the privileges available to the agent and separates ordinary development work from sensitive operations.

Useful controls include:

Short-lived credentials. Prefer credentials that expire quickly and can be restricted to a particular task.

Scoped permissions. Give the agent access to the repository, service, or resource it actually needs.

Environment isolation. Run untrusted code and package installation in disposable or restricted environments.

Human approval for sensitive actions. Require review before destructive operations, permission changes, production deployments, or release publication.

Secret minimization. Avoid placing production credentials in prompts, logs, generated files, or environments that do not require them.

Auditability. Record relevant tool calls, permission changes, deployment decisions, and execution failures.

These controls do not eliminate every attack, but they reduce the consequences when something goes wrong.

7. Python Startup Hooks: Why Importing a Library May Not Be the First Execution Point#

The LiteLLM incident highlights an important detail about Python environments.

Developers often imagine that a library can execute code only when the application imports it:

import some_library

That is an oversimplification.

Python has mechanisms that can execute code during interpreter startup. For example, .pth files in site directories can contain executable import lines, and the sitecustomize module may be imported during normal site initialization when available.

These mechanisms have legitimate uses, but they also mean that the security boundary can begin before the application's main code runs.

Microsoft's investigation of the LiteLLM incident reported malicious components that used Python startup behavior, meaning that an affected interpreter could execute code without the application explicitly importing the compromised package.

Why is this significant?#

Suppose an application has a carefully reviewed entry point:

Application Startup
        |
        v
Input Validation
        |
        v
Authentication
        |
        v
Business Logic

That view assumes the application reaches its entry point before any unexpected code executes.

But interpreter initialization occurs earlier in the process.

A safer mental model is:

Process Starts
      |
      v
Runtime Initialization
      |
      v
Startup Configuration and Hooks
      |
      v
Application Entry Point
      |
      v
Business Logic

The exact startup sequence depends on the runtime and environment. The point is that security reviews should consider initialization behavior, not only explicit application imports.

What should developers do?#

• Install packages only from trusted sources.
• Use isolated environments for development and CI jobs.
• Inspect unexpected changes to package files and startup configuration.
• Keep dependency installation separate from privileged deployment operations.
• Restrict the credentials available to build and test jobs.
• Monitor unexpected processes, network connections, and filesystem changes.
• Preserve the lockfile and the artifact information needed to reproduce the environment.

Avoid treating package installation as a harmless preparation step. Installing a dependency changes what code may execute in the environment.

8. Build a Safer Dependency Pipeline: A Practical Experiment#

You can test several supply-chain controls without reproducing a real attack or using malicious software.

The objective is to create a small CI pipeline that verifies dependencies and rejects an artifact that does not meet your policy.

This exercise is useful for AI agents, backend services, Python projects, and containerized applications.

Step 1: Create a disposable repository#

Use a test repository that contains no production credentials and has no access to sensitive services.

Add a minimal application and a dependency manifest.

The repository should have a simple build process that can run in an isolated CI environment.

Step 2: Lock the dependencies#

Resolve the project's dependencies and create a lockfile.

The pipeline should install the declared versions rather than selecting arbitrary new releases during each build.

Record the dependency versions used by the test environment.

Remember that a lockfile improves reproducibility. It does not, by itself, prove that every package is safe.

Step 3: Record artifact digests#

For the artifacts used in the exercise, record their cryptographic digests in a trusted test manifest.

During the build, verify that each downloaded artifact matches the expected digest.

For the exercise, use harmless packages and test artifacts that you control.

Step 4: Verify provenance where available#

If your build system and artifact registry support provenance attestations, configure the pipeline to check the expected repository, source revision, and builder identity.

Define the policy before running the test.

For example, a release might be accepted only when its provenance identifies the approved repository and CI workflow.

If provenance is missing or does not match the policy, the pipeline should stop.

Step 5: Restrict the pipeline's permissions#

Do not provide the test job with production credentials.

Give it only the permissions needed to install dependencies, run tests, and create the intended test artifact.

If a later stage needs permission to publish a release, give that permission only to the specific stage that requires it.

This helps limit the consequences of a compromised dependency or build step.

Step 6: Test a verification failure#

Now introduce a harmless mismatch into the test fixture.

For example, change the expected digest recorded in the test manifest while leaving the artifact unchanged.

The verification step should detect the mismatch and fail the build.

Do not weaken the check or silently replace the expected value with the observed digest.

The purpose is to confirm that the pipeline actually enforces the intended policy.

Step 7: Record the result#

Save:

• The dependency lockfile.
• The artifact digest manifest.
• The provenance verification output, where available.
• The CI configuration.
• The build logs.
• The final pass or fail result.

The exercise is successful when the pipeline accepts the known-good test artifact and rejects the deliberately mismatched one.

What should you measure?#

You can evaluate the pipeline using a simple checklist.

This does not prove that your software is free from vulnerabilities. It demonstrates that certain supply-chain controls are working as designed.

The same principle applies to a production pipeline, although production policies need to account for the capabilities of the actual build and deployment platforms.

9. Runtime Inventory Must Be Automated#

Security teams cannot patch vulnerabilities they do not know exist.

A common problem in growing software organizations is that runtime and dependency information is spread across configuration files, container images, cloud services, developer machines, and deployment environments.

A spreadsheet updated manually may be useful for an initial inventory, but it is not a reliable long-term source of truth.

What should an inventory include?#

For a PHP application, record:

• The service and deployment environment.
• The PHP version.
• The operating system or container image.
• The hosting platform.
• The patch status.
• The date the inventory was last verified.

For AI infrastructure, extend the inventory to include:

• Model gateways.
• Agent runners.
• Python and JavaScript environments.
• LLM integration libraries.
• Container images.
• Package and model-serving dependencies.
• CI/CD workflows.
• Credentials and permission boundaries.
• Production and staging deployments.

The objective is to understand what is deployed, what it depends on, and what access it has.

Automate the checks#

Where practical, configure CI and deployment systems to:

1. Record runtime and dependency versions.
2. Detect known vulnerabilities.
3. Check whether required patch baselines are met.
4. Verify the expected artifact and provenance information.
5. Flag deployments that do not meet security policy.
6. Preserve enough information to investigate an incident.

Also check the runtime that is actually deployed. A pipeline may build with one version while production continues to run another.

Automated checks make security requirements repeatable. They also reduce the time between the discovery of a vulnerability and identifying which services need attention.

10. Incident Response: Removing the Vulnerable Package Is Only the Beginning#

When a dependency or runtime is compromised, teams often focus first on removing the affected version.

That is necessary, but it may not be sufficient.

The correct response depends on what happened in the environment.

If a vulnerable runtime was exposed, you need to establish whether exploitation may have occurred.

If a malicious package executed in an environment with sensitive credentials, you need to consider whether those credentials were accessed.

If a build pipeline was compromised, you need to establish whether other artifacts were published or deployed.

A practical incident-response sequence#

1. Establish exposure. Determine which services, machines, containers, packages, and time periods may have been affected.

2. Contain the incident. Isolate affected environments or disable compromised workflows where appropriate.

3. Preserve evidence. Retain relevant logs, build records, package information, and available telemetry before rebuilding or deleting affected environments.

4. Rotate exposed credentials. Replace potentially compromised tokens and keys, and revoke old credentials. Prioritize credentials with broad access.

5. Rebuild from trusted sources. Use verified source revisions, clean build environments, trusted artifacts, and known-good configurations.

6. Validate the replacement. Confirm the deployed versions, permissions, dependencies, and artifact provenance.

7. Review for persistence and unauthorized activity. Investigate suspicious access, unexpected changes, and other signs of compromise.

8. Document the incident. Record what was affected, how it was contained, what was changed, and which questions remain unresolved.

This is a general response framework, not a substitute for a vendor's incident-specific instructions or a formal incident-response plan.

The key distinction is between removing the component that caused the problem and restoring trust in the environment where it ran.

Those are related but separate tasks.

11. A Security Checklist for AI Agent Infrastructure#

If you are building an AI agent that can execute code, install packages, modify repositories, or access external services, use the following checklist as a starting point.

Dependencies and artifacts#

• Maintain a dependency lockfile.
• Review dependency changes before merging them.
• Verify artifact hashes against trusted expected values.
• Validate provenance where supported.
• Prefer reproducible and auditable build processes.
• Track the source revision associated with each release.
• Rebuild artifacts when trust in the original build process is lost.

Runtimes and containers#

• Inventory the runtime versions actually deployed.
• Monitor official security advisories.
• Patch supported runtime branches promptly.
• Plan migrations away from unsupported versions.
• Rebuild and redeploy patched container images.
• Verify the running version after deployment.

CI/CD and credentials#

• Use least-privilege permissions for build jobs.
• Avoid exposing production secrets to ordinary test jobs.
• Prefer short-lived credentials where supported.
• Restrict release publication permissions.
• Require review for sensitive workflow changes.
• Preserve build logs and artifact records.
• Test that verification failures stop publication.

AI agents and execution environments#

• Run untrusted code in isolated environments.
• Limit repository, filesystem, and network access.
• Separate agent planning from permission enforcement.
• Require approval for sensitive or destructive actions.
• Keep secrets out of prompts and generated files.
• Log relevant tool calls and failures.
• Test failure behavior and recovery procedures.

Incident readiness#

• Know which artifacts are deployed.
• Maintain a process for revoking credentials.
• Know how to rebuild from trusted sources.
• Preserve evidence needed for investigation.
• Have a plan for affected dependencies and runtimes.
• Test the recovery process before a real incident occurs.

Not every control will be equally important for every application. Prioritize according to the privileges of the environment, the sensitivity of the data, the exposure of the service, and the consequences of a compromise.

---

Conclusion: Trust the Evidence, Not Just the Version Number#

The PHP and LiteLLM incidents illustrate two different ways software security can fail.

The PHP vulnerabilities show that an application can inherit serious risk from the runtime responsible for executing it.

The LiteLLM compromise shows that a trusted package name and version do not automatically establish that the published artifact matches the source code a developer reviewed.

Together, these cases demonstrate why application security, dependency management, artifact provenance, credential management, and incident response must work as one system.

This matters even more for AI infrastructure because agents and model gateways may have access to source repositories, external services, cloud resources, and credentials that are valuable to an attacker.

The answer is not to stop using dependencies or abandon automation. It is to make the boundaries between components more explicit and verify them wherever practical.

Start with a concrete inventory. Know which runtimes and artifacts are deployed, where they came from, and what privileges they have.

Then automate the checks that can be automated, restrict unnecessary access, and test how your system behaves when a check fails.

Most importantly, prepare to restore trust after an incident rather than assuming that deleting a vulnerable package resolves every consequence.

Dependency pinning is a good foundation. It is not a complete supply-chain security strategy.

For AI engineers, building reliable systems means thinking beyond the model and the application code. It means securing the entire environment in which the agent operates, from the source revision to the artifact, from the runtime to the credentials, and from the initial deployment to the recovery process.

---

Official References and Further Reading#

1. PHP: Security Advisory Archive
   Official information about PHP security updates, including the October 21, 2026 critical vulnerabilities and patched releases.
   PHP Security Advisories

2. LiteLLM: October 21, 2026 Release Security Incident
   The project's incident report covering the affected release, package and container artifacts, and remediation information.
   LiteLLM Security Incident Report

3. Microsoft Security Research: Inside the LiteLLM 1.107.0 Supply-Chain Compromise
   Technical analysis of the compromised release and its credential-theft behavior.
   Microsoft Security Analysis

4. LiteLLM: The Attack Chain Behind the v1.107.0 Release
   The project's follow-up analysis of the incident and the release pipeline.
   LiteLLM Attack-Chain Analysis

---

About the Author#

Sameer Bagul is an AI Engineer, Full-Stack Developer, and AI Product Builder interested in AI infrastructure, agentic systems, software security, and building reliable production-grade AI applications.