When thousands of customers arrive within a short period, every layer of the platform can come under pressure. Customers browse products, search catalogs, apply promotions, check inventory, add items to carts, make payments, and place orders—creating sudden demand across applications, databases, APIs, caches, and third-party services.

A platform that performs perfectly during normal traffic can behave very differently during a major promotional event. The challenge is therefore not simply adding more servers, but building an ecommerce infrastructure that can absorb traffic spikes, protect critical transactions, and recover when individual components fail.

Start With Peak Traffic Capacity Planning

Most systems are designed around normal traffic. Black Friday requires a different approach.

Peak traffic capacity planning should consider several scenarios instead of relying on a single traffic estimate:

• Normal daily traffic

• Expected Black Friday peak

• Higher-than-expected demand

• Sudden traffic spikes

• Recovery after the peak

For example, a promotional campaign may cause traffic to increase rapidly within minutes. If capacity is added only after CPU utilization becomes critical, customers may already be experiencing slow pages or failed transactions.

Teams should therefore identify capacity limits before the event.

Questions worth answering include:

• How many concurrent users can the application support?

• How quickly can additional capacity become available?

• What happens when database connections are exhausted?

• Which APIs have fixed quotas?

• How much traffic can the CDN absorb?

• What happens if a third-party dependency becomes slow?

This provides a more realistic foundation for cloud scalability.

Design Ecommerce Cloud Architecture Around Bottlenecks

A modern ecommerce platform may contain load balancers, application servers, containers, managed databases, caches, queues, APIs, payment providers, and third-party services.

The challenge is that these components do not necessarily scale at the same speed.

This is why ecommerce cloud architecture should be designed around bottlenecks rather than simply increasing compute capacity.

Imagine an application cluster that can scale from 20 instances to 200. If every new instance creates additional database connections, the database may become the actual bottleneck.

In that situation, adding more application capacity could make the problem worse.

Architecture reviews should therefore examine:

• Database connection limits

• API quotas

• Cache behavior

• Queue capacity

• Network limits

• Synchronous dependencies

• Third-party services

• Storage performance

• Application scaling speed

Organizations preparing for major seasonal demand can also review their broader cloud environment through Infosprint Cloud Computing Services, covering areas such as infrastructure modernization, scalability, optimization, security, and reliability.

Build a Scalable Ecommerce Platform

A scalable ecommerce platform should be capable of handling increased workload without requiring engineers to manually provision resources during the event.

Horizontal application scaling is commonly used for this purpose. Additional application instances can be added as demand increases.

However, scaling speed matters.

A typical reactive scaling process may need to:

1. Detect increased utilization.

2. Trigger a scaling policy.

3. Provision capacity.

4. Start the application.

5. Pass health checks.

6. Establish connections.

7. Warm caches.

8. Accept production traffic.

If demand grows faster than these steps complete, customers may experience degradation before the new resources are ready.

This is why black friday autoscaling should not be treated as a complete Black Friday strategy.

Use Auto Scaling Architecture With a Capacity Buffer

A strong auto scaling architecture combines reactive scaling with proactive preparation.

For predictable events, teams can increase minimum capacity before the expected peak. Scheduled or predictive scaling can also help reduce the time required to respond to demand.

Queues provide another useful mechanism. Non-critical background work can be buffered instead of competing directly with checkout traffic.

Graceful degradation is equally important.

During extreme demand, the platform might prioritize:

• Product availability

• Cart operations

• Checkout

• Payment

• Order creation

Meanwhile, less critical workloads such as recommendations, personalization, analytics, or background processing can be reduced temporarily.

The objective is not to keep every feature operating identically. The objective is to keep the revenue-generating transaction working.

Treat Black Friday Database Performance as a Priority

One of the most common architectural mistakes is focusing heavily on application scaling while treating database capacity as an afterthought.

That can create serious problems.

A checkout transaction may involve pricing, promotions, inventory, customer data, payment information, and order creation. When thousands of customers perform these operations simultaneously, database workload can increase dramatically.

Black friday database performance should therefore be tested as carefully as application performance.

Teams should examine:

• Slow queries

• Missing indexes

• Connection pool limits

• Lock contention

• Read/write patterns

• Replication lag

• Cache effectiveness

• Transaction duration

• Storage throughput

Caching can reduce repeated reads, while queues can move non-critical operations away from synchronous requests. Read replicas may also help where the workload is read-heavy.

The key is to identify database bottlenecks before customers encounter them.

Make Ecommerce Performance Testing Realistic

A homepage load test does not represent a real ecommerce workload.

Customers move through multiple steps:

Search → Product Page → Cart → Promotion → Checkout → Payment → Order

Each step can touch different services.

Effective ecommerce performance testing should therefore simulate realistic customer journeys and measure more than requests per second.

Useful metrics include:

• API latency

• Page response time

• Database latency

• Error rates

• Queue depth

• Cache hit rate

• Checkout success rate

• Payment failures

• Order creation latency

• Resource saturation

The purpose is to understand where the customer journey begins to degrade.

Run Black Friday Load Testing Before the Event

Black Friday load testing should happen early enough for engineers to fix the problems it exposes.

A useful testing sequence includes:

Baseline Testing

Measure the platform under normal production-like traffic.

Peak Testing

Test the expected Black Friday workload.

Stress Testing

Increase traffic beyond the expected level to find system limits.

Spike Testing

Introduce a sudden traffic increase to determine how quickly the platform responds.

Recovery Testing

Reduce traffic and verify that the system returns to normal.

Failure Testing

Degrade or remove selected dependencies and observe the impact.

This process provides much more useful information than simply running one large performance test a few days before Black Friday.

Design High Availability and Failover Together

Capacity alone cannot prevent every outage.

A database failure, network issue, cloud service disruption, or third-party dependency can still interrupt transactions.

This is where high availability cloud architecture becomes important.

The architecture should reduce dependency on individual failure points across application instances, availability zones, databases, networking components, and external services.

But redundancy is only useful if the system can actually switch to it.

That is why failover mechanisms need to be designed and tested as part of the application architecture.

A recovery environment may appear healthy while still failing to process orders if payment callbacks, secrets, databases, queues, or routing configurations are missing.

A proper failover test should therefore validate the entire transaction path.

Prepare for Multi Region Disaster Recovery

For businesses that require stronger resilience, multi region disaster recovery can provide protection against major regional failures.

However, having infrastructure deployed in a second region does not automatically create disaster recovery.

Teams need clear procedures for:

• Traffic routing

• Database replication

• Data consistency

• Application configuration

• Secrets

• Session management

• Inventory synchronization

• Payment processing

• DNS changes

• Recovery objectives

This makes black friday disaster recovery an engineering capability rather than simply a document.

The recovery process should be rehearsed before the event.

Prevent a Black Friday Website Crash With Observability

A black friday website crash is often discovered by customers before engineers understand what is happening.

Infrastructure metrics alone may not reveal the complete problem.

A dashboard could show healthy CPU and memory while customers experience checkout failures.

Black Friday monitoring should therefore track both infrastructure and business transactions.

Important signals include:

• Checkout success rate

• Payment authorization rate

• Order creation rate

• Cart errors

• API latency

• Database latency

• Queue depth

• Regional traffic

• Application errors

This allows engineering teams to connect technical problems with actual customer and revenue impact.

Build a Black Friday Readiness Checklist

Before the event, engineering teams should be able to answer “yes” to questions such as:

• Have peak traffic scenarios been modeled?

• Has application scaling been tested?

• Has database performance been tested under realistic concurrency?

• Have autoscaling policies been validated?

• Has the complete checkout journey been load tested?

• Are critical services protected against single points of failure?

• Have failover mechanisms been executed successfully?

• Has disaster recovery been rehearsed?

• Can engineers see customer transaction health in real time?

• Are escalation responsibilities clearly defined?

If several answers are “no,” simply increasing cloud capacity may not solve the underlying risk.

Final Takeaway

Black Friday readiness is not about buying more infrastructure at the last minute.

It is about understanding how the entire transaction path behaves under pressure.

Cloud scalability needs to cover application capacity, databases, APIs, queues, caching, dependencies, and recovery processes.

A reliable ecommerce platform should be able to absorb ecommerce traffic spikes, protect checkout, detect bottlenecks quickly, and recover when individual components fail.

The strongest approach is to model peak demand, test realistic customer journeys, optimize the database, validate black friday autoscaling, rehearse failover mechanisms, and prove that disaster recovery actually works.

When engineering teams approach Black Friday as an architecture and reliability exercise rather than simply a traffic event, they can turn peak demand into a controlled engineering challenge.

Ultimately, that requires a combination of ecommerce cloud architecture & cloud scalability.

It passes through repositories, dependencies, build systems, CI/CD pipelines, package managers, deployment tools, cloud environments, and increasingly AI coding assistants.

That creates a problem that traditional application security does not completely address.

The software can be trusted by the organization and still introduce risk.

This is where software supply chain security becomes important.

The question is no longer only whether the application itself is secure. Organizations also need to understand what enters the application, who or what changes it, how it moves through the development pipeline, and what eventually receives production access.

The Software Pipeline Is Part of the Security Boundary

A modern development pipeline can contain dozens of interconnected components.

A typical workflow may involve:

• Source-code repositories

• Open-source dependencies

• Package registries

• Build servers

• CI/CD workflows

• Container images

• Infrastructure-as-code

• Deployment platforms

• Cloud services

• Third-party integrations

• AI coding assistants

Each component can introduce a dependency that the security team may not directly control.

This means the traditional idea of protecting the application perimeter is becoming less useful.

The pipeline itself has become part of the environment that needs protection.

Why Trusted Code Can Still Become a Problem

One of the difficult characteristics of supply-chain risk is that malicious activity does not always look malicious at first.

A compromised dependency may still appear legitimate.

A modified package may successfully pass through an automated build.

A compromised developer account may use legitimate credentials.

A CI/CD workflow may execute exactly as it was designed to execute.

The problem is that the trust relationship has already been established.

This is why software supply chain attacks can be particularly difficult to identify.

The attacker does not necessarily need to break through the final production environment.

They may instead find a trusted point earlier in the development process.

The Build Pipeline Deserves the Same Attention as Production

Security teams have traditionally concentrated heavily on production systems.

That makes sense. Production contains the applications and data that organizations are trying to protect.

But development infrastructure can have an equally important position in the chain.

Consider what a CI/CD pipeline may be able to access:

• Source code

• Secrets

• Cloud credentials

• Package repositories

• Deployment environments

• Container registries

• Production systems

If an attacker gains control of a sufficiently privileged build process, the attacker may be able to influence what eventually reaches production.

That changes the security question from:

"Is our production application secure?"

to:

"Can we trust everything that was allowed to become part of our production application?"

That distinction is central to effective software supply chain security.

Dependencies Create Another Layer of Risk

Modern applications depend heavily on third-party and open-source software.

This provides enormous development advantages.

Teams do not need to build every component themselves. They can reuse established libraries, frameworks, packages, and tools.

But every dependency also creates another relationship that needs to be understood.

Organizations need visibility into questions such as:

• Which dependencies are being used?

• Where did they come from?

• Which versions are deployed?

• Who maintains them?

• What happens when a dependency changes?

• Which applications depend on a particular package?

• Can a compromised package enter the build automatically?

Without that visibility, organizations may discover a problem only after the dependency has already reached multiple applications.

Security Has to Follow the Software

A major challenge is that software continuously changes.

A security review performed once at the beginning of a project cannot account for every dependency, code change, build, deployment, or configuration modification that happens afterward.

Security therefore needs to become part of the software lifecycle.

That means organizations should consider controls around:

Source

Protect repositories, developer identities, branches, and code changes.

Dependencies

Understand what third-party and open-source components are entering applications.

Build

Restrict who and what can modify or execute build processes.

Verification

Establish confidence that the artifact being deployed is the artifact that was intended.

Deployment

Control which identities and systems can move software into production.

Monitoring

Continue watching what happens after deployment rather than treating security as complete once the application is released.

This approach makes security part of the architecture rather than a final checkpoint.

Where Cybersecurity Services Fit

Technology alone does not automatically create a secure software lifecycle.

Organizations often have multiple tools covering source-code security, cloud security, identity, application security, DevOps, and monitoring.

The bigger challenge is connecting those controls into an operating model.

A cybersecurity service can help organizations assess those relationships across the environment, identify where trust is excessive, and establish controls around identities, applications, infrastructure, and development workflows.

The objective should not simply be to add another security product.

It should be to understand where software is trusted, why it is trusted, and what that trust allows it to do.

AI Is Adding Another Layer to the Software Lifecycle

AI coding assistants and AI development agents are increasingly becoming part of software development.

They can generate code, modify existing code, suggest dependencies, create tests, and accelerate development workflows.

That can improve productivity.

But it also means organizations need to understand how AI-generated changes enter existing development processes.

The important question is not whether AI-generated code is automatically unsafe.

It is whether the same verification, review, identity, dependency, and deployment controls apply regardless of how the code was produced.

If a development workflow automatically trusts changes because they came through an approved process, the origin of the change becomes less important than the controls surrounding that process.

What Organizations Should Review

A practical review of the software lifecycle should start with a few straightforward questions.

Who can change the code?

Who can modify dependencies?

Who can execute the build?

Which credentials can the pipeline access?

Can developers or automation bypass required reviews?

Can an unverified artifact reach production?

Can the organization trace what changed between development and deployment?

What happens when a trusted component becomes compromised?

These questions help expose gaps that may remain invisible when each security control is evaluated separately.

The Goal Is Not Zero Trust in Everything

Software supply chain security does not mean treating every developer, package, tool, or pipeline as malicious.

The practical goal is more precise:

Trust should be earned, limited, verified, and continuously evaluated.

A package should not receive unnecessary privileges simply because it is widely used.

A build system should not automatically receive unrestricted production access.

A developer identity should not have more permissions than the development workflow requires.

And a production deployment should not depend on an artifact whose origin cannot be established.

This creates a more defensible software lifecycle without preventing development teams from moving quickly.

Conclusion

The modern software environment is built on relationships.

Applications depend on packages.

Developers depend on tools.

Build systems depend on credentials.

Deployments depend on automation.

And production depends on everything that happened before deployment.

That is why software supply chain security is becoming an architectural concern rather than simply another security checklist item.

Organizations that understand these dependencies can reduce unnecessary trust, improve visibility across the development lifecycle, and make it harder for software supply chain attacks to move from a trusted component into production.

The strongest approach is not to wait until a trusted system fails.

It is to understand what is trusted, what it can access, and what it is allowed to change before it reaches production.

For organizations evaluating their broader cybersecurity service strategy, this is an important place to start: secure the software lifecycle, limit unnecessary access, and verify the path from code to production.

The important question is no longer:

Can someone tell whether the voice is fake?

It is:

What can that fake identity actually do?

That shift changes how security teams should think about BEC, vishing, identity verification, and access control.

Why Traditional BEC Defenses Are Under Pressure

Business email compromise already works by abusing trust.

An attacker might impersonate a finance executive and request a wire transfer. Another might pretend to be a vendor and ask for updated banking information. A third might impersonate an internal employee and request access to a system.

Most of these attacks rely on one basic assumption:

The person making the request is legitimate.

Organizations have traditionally tried to validate that assumption with signals such as:

• email addresses

• caller ID

• signatures

• known contacts

• video meetings

• employee names

• familiar writing styles

Those signals can still be useful.

They just shouldn't be treated as proof by themselves.

AI-generated media gives attackers another way to manufacture those signals.

The Multi-Channel Attack

Consider a simple example.

A finance employee receives an email:

“Please prepare the acquisition payment. I’ll call you.”

The employee notices that the request is unusual.

So they wait for the call.

A few minutes later, the CFO calls.

The voice sounds familiar.

The caller knows the project.

Then a Teams message appears:

“Proceed. I’m going into another meeting.”

Nothing looks obviously wrong.

This is where the traditional security model breaks.

The employee did not ignore security training.

They tried to verify the request.

But the attacker controlled the verification path.

This is one reason vishing attacks are becoming more difficult to distinguish from legitimate executive communication.

The FBI has documented campaigns in which attackers used AI-generated voice messages to impersonate senior U.S. officials, build rapport, and move targets into additional communication channels. The agency recommends independently identifying a trusted phone number and calling back instead of trusting the contact information included in the original communication.

The Verification Channel Can Become the Attack Surface

This is an important design problem.

Security teams often think of communication channels like this:

Email = lower trust

Phone = higher trust

Video = higher trust

But AI-generated media makes that hierarchy less useful.

A phone call can be synthetic.

A video can be manipulated.

Caller ID can be spoofed.

A messaging account can be compromised.

So the security model needs another layer:

Communication ≠ authorization

A communication can provide context.

Authorization should come from a separate control.

Verify the Action, Not Just the Identity

This is the most useful principle for defending against deepfake fraud.

Instead of:

“Is this the CFO?”

ask:

“Is this transaction independently authorized?”

That distinction lets organizations move the burden away from human perception and into system design.

For example:

High-value payment

Require two authorized approvers.

New beneficiary

Require independent verification using a trusted contact path.

Bank-account change

Require confirmation outside the original communication channel.

Privileged-access request

Require strong authentication and a separate authorization step.

Emergency change

Require an additional approval path even when the requester appears legitimate.

The goal is not to make the employee better at spotting AI.

The goal is to make impersonation insufficient to complete the action.

Where Identity Architecture Comes In

Deepfake defense is closely connected to modern identity architecture.

And this doesn't only mean human identity.

Enterprise environments increasingly depend on Non-Human Identities (NHIs):

• service accounts

• API identities

• workload identities

• automation accounts

• AI agents

• integration credentials

These identities can have access to systems without any human sitting behind every action.

That makes least privilege especially important.

An AI agent that can modify production resources should not receive a permanent, unrestricted API credential.

Prefer:

• scoped API tokens

• short-lived or ephemeral credentials

• workload identities

• explicit ownership

• production and development separation

• access expiration

• detailed logging

• automated disablement

This same principle applies to human users.

A CFO may have the authority to approve a payment.

That does not mean every communication that appears to come from the CFO should be enough to authorize it.

Identity establishes who someone appears to be. Authorization determines what they are allowed to do.

Deepfake Fraud Meets AI Agent Security

This is where two areas of security increasingly overlap.

On one side:

Attackers use AI to imitate people.

On the other:

AI agents are gaining permission to act on behalf of organizations.

Both create the same architectural question:

What happens when the identity is not behaving as expected?

Recent AI-agent incidents reinforce this point.

Replit reported changes after an AI-agent incident involving production data, including stronger separation between development and production environments.

PocketOS's founder also reported a production database deletion involving a coding agent and cloud API access.

Neither is a deepfake case.

But the security lesson is relevant:

A policy is not enough if the system still has permission to violate it.

“Do not touch production” is weaker than a technical control that makes production modification impossible.

“Only the CFO can authorize this payment” is weaker than a workflow that requires independent transaction approval.

Why Detection Alone Isn't Enough

There is growing interest in voice cloning detection and other deepfake-detection technologies.

They have value.

Detection can identify suspicious audio or behavioral patterns and give security teams another signal.

But detection should not become the only line of defense.

A detection model can miss:

• new generation techniques

• unfamiliar voices

• different delivery channels

• synthetic media that falls within expected patterns

A stronger architecture combines:

Detection

Identity verification

Transaction controls

Least privilege

Independent approval

Monitoring

That model remains useful even when the deepfake itself passes human or automated detection.

A Practical Security Checklist

For security engineers and architects, start by identifying the workflows where a convincing identity could trigger a high-impact action.

Ask:

Can one person approve a large payment?

Can a new beneficiary be created without independent verification?

Can a helpdesk operator reset privileged credentials after a voice request?

Can an AI agent use a reusable credential to modify production?

Can a service account retain access after its task is complete?

Can the organization stop an unusual transaction before the money or data leaves the environment?

These questions are more useful than simply asking whether the organization owns a deepfake detector.

A 30-Day Starting Point

Week 1: Map identity

Identify human and non-human identities that can initiate high-impact actions.

Week 2: Map authorization

Document payment, access, beneficiary, and emergency workflows.

Look for places where a communication is treated as authorization.

Week 3: Review credentials

Inventory AI agents, service accounts, API tokens, and production permissions.

Prioritize long-lived and overly broad access.

Week 4: Test the process

Run a controlled executive impersonation or vishing exercise.

Measure whether employees:

• recognize the unusual request

• use an independent verification channel

• follow the approval process

• avoid bypassing controls under pressure

The goal is not to test whether employees can identify a perfect deepfake.

The goal is to test whether the organization remains safe when they cannot.

Where to Go From Here

A strong deepfake defense doesn't require abandoning traditional security awareness.

It requires adding another layer to it.

Employees should still report suspicious messages.

Security teams should still monitor unusual authentication activity.

Finance teams should still investigate unusual payment requests.

But the architecture should assume that some attacker-generated content will eventually look legitimate.

That means high-impact actions need controls that are independent of appearance, voice, and familiarity.

The Core Principle

A voice can be cloned.

A face can be synthesized.

An email can be compromised.

A caller ID can be manipulated.

The authorization should still be real.

Instead of simply answering a question, an agent can retrieve information, call an API, read a document, update a system, trigger another workflow, or hand work to another agent.

That changes the security conversation.

A chatbot that only generates text has a different risk profile from an AI agent that can access a CRM, query an internal database, create a ticket, modify a cloud resource, or send information to an external service.

This is where enterprise AI governance becomes important.

It is no longer enough to ask whether the underlying AI model is safe. Organizations also need to understand what the agent can access, what it is allowed to do, which tools it can use, and what happens when something goes wrong.

The agent is not the model

One of the easiest mistakes to make when discussing AI security is treating the LLM as the entire system.

In practice, an enterprise agent often looks more like this:

User

  ↓

AI Agent

  ↓

LLM

  ↓

Tools / APIs

  ↓

Enterprise Applications

  ↓

Business Data

The LLM provides reasoning and language capabilities, but the surrounding application determines what the agent can actually do.

For example, an organization might use GPT, Claude, Gemini, or another model as the reasoning engine.

The model could be excellent at understanding a request.

But if the application gives that model unrestricted access to production APIs, databases, file systems, or administrative functions, the security problem is no longer just a model problem.

It becomes an architecture and permissions problem.

That distinction is becoming increasingly important as AI agents become more capable.

The UK AI Security Institute has been evaluating AI agents in realistic environments, including scenarios involving cyber activity and multi-step actions. Its research has also found that model capability alone does not fully determine how robust an agent is against attacks. 

Identity should come before autonomy

If an AI agent can take an action, the enterprise should be able to answer a simple question:

Who performed the action?

With traditional software, this is usually handled through service accounts, users, roles, API credentials, or workload identities.

AI agents need the same discipline.

An agent should have an identifiable identity rather than operating through a shared administrator credential.

For example:

Customer Support Agent

        ↓

Agent Identity

        ↓

Read-only CRM access

        ↓

Customer ticket data

That is much easier to control than:

AI Agent

        ↓

Shared enterprise account

        ↓

Everything

The first approach creates a clear security boundary.

The second creates an accountability problem.

OWASP's current agentic AI security work specifically identifies agent identity and privilege abuse as important areas of concern. 

Least privilege applies to AI agents too

Giving an agent access to a tool does not mean giving it unrestricted access to that tool.

Consider an internal reporting agent.

It may need to:

• Read sales data

• Generate reports

• Query specific databases

• Export approved reports

It probably does not need to:

• Delete records

• Change database permissions

• Create administrator accounts

• Modify production infrastructure

This is where least privilege becomes practical.

OWASP's AI Agent Security guidance recommends giving agents only the tools required for their specific tasks and applying permission scoping at the tool level. 

A useful rule is:

If an agent does not need a permission to complete its job, do not give it that permission.

This sounds obvious, but agent architectures can make permissions surprisingly difficult to track because one agent may call several tools, and those tools may have their own permissions.

Tool access is part of the attack surface

An agent may be safe when it only generates text.

Add a browser tool, database connector, shell access, cloud API, email integration, or payment API, and the risk profile changes.

For example:

LLM

 ↓

Browser

 ↓

External website

is different from:

LLM

 ↓

Browser

 ↓

Internal application

 ↓

Customer records

The second workflow requires much stronger controls.

This is why AI security cannot be evaluated only by looking at the model's responses.

Security teams should also test what happens when the model is connected to real tools.

Can it access information outside its intended scope?

Can it call an API that it should not have access to?

Can an untrusted document influence the agent's behavior?

Can it execute a sensitive operation without approval?

These are architectural questions, not just prompt questions.

Human approval still has a role

The goal of enterprise AI should not necessarily be to keep a human involved in every single action.

That would remove much of the value of automation.

Instead, organizations should distinguish between low-risk and high-impact actions.

For example:

OWASP's current agentic security guidance similarly recommends explicit human approval for high-impact or irreversible actions.

The important concept is controlled autonomy.

An agent should be allowed to move quickly where the consequences are small and slow down when the consequences are significant.

Data access needs its own boundary

AI agents can create another difficult problem: data movement.

Imagine an agent that can access:

• Internal documents

• Customer information

• HR systems

• Source code

• Cloud infrastructure

• External AI services

Even if every individual connection appears reasonable, the combined workflow can create unexpected data exposure.

Organizations therefore need visibility into:

1. What data the agent can access

2. What data it retrieves

3. Where that data goes

4. Which model processes it

5. Which tools receive it

6. How long it is retained

7. Who can access the resulting output

This is especially important when third-party models or external services are involved.

Data classification should therefore happen before the agent is connected to enterprise systems, not after deployment.

Monitoring needs to follow the agent

Traditional application logging often focuses on requests and responses.

Agentic systems need a broader audit trail.

A useful log should help answer:

Who initiated the task?

Which agent handled it?

Which model was used?

What tools were called?

What data was accessed?

What permissions were used?

Which external systems were contacted?

Was human approval required?

What action was ultimately performed?

Without this information, investigating an unusual agent action can become extremely difficult.

This is one reason governance and security need to be designed together.

The current OWASP agentic security guidance also emphasizes monitoring, identity, tool controls, human oversight, and containment as part of the broader security model. 

A practical AI governance roadmap

Organizations do not need to build a perfect governance program before deploying their first useful AI workflow.

A better approach is to build it in stages.

Step 1: Create an AI inventory

Start by identifying:

• AI models

• AI applications

• Agents

• APIs

• Data sources

• Users

• Service identities

• Third-party AI providers

You cannot govern what you cannot see.

Step 2: Map permissions

For every agent, document:

What can it read?

What can it write?

Which tools can it call?

Which systems can it access?

Which actions require approval?

This turns an abstract AI risk problem into something security teams can actually evaluate.

Step 3: Classify the use case

Not every agent deserves the same controls.

A meeting-notes agent and an autonomous infrastructure agent should not be governed identically.

Risk classification can consider:

• Data sensitivity

• Level of autonomy

• Business impact

• External connectivity

• Permission scope

• Reversibility of actions

Step 4: Test before expanding access

Before giving an agent additional permissions, test it.

Try to determine whether it can:

• Access restricted information

• Misuse tools

• Follow malicious instructions

• Perform unauthorized actions

• Escape intended workflow boundaries

• Trigger unexpected downstream behavior

AISI's recent agent research demonstrates why testing realistic multi-step behavior matters rather than relying only on conventional model benchmarks. 

Step 5: Monitor continuously

AI governance is not something you finish once.

Models change.

Agent instructions change.

Tools change.

APIs change.

Permissions change.

New vulnerabilities appear.

A governance program therefore needs continuous monitoring and periodic reassessment.

Where cybersecurity fits

AI governance should not become a completely separate island inside an organization.

A lot of the required controls already exist within cybersecurity programs.

Identity and access management can help control agent permissions.

Data security can protect sensitive information.

Application security can evaluate the APIs and applications connected to agents.

Security monitoring can detect unusual behavior.

Incident response can provide a process for investigating unexpected agent activity.

This is also why organizations should look at their existing cybersecurity solutions when building AI security controls instead of assuming that every AI risk requires a completely new security stack.

The newer requirement is to apply these controls to systems where software can reason, select tools, and perform actions dynamically.

The bigger shift

The most important change brought by AI agents is not simply that models are getting smarter.

It is that software is becoming increasingly capable of making decisions and interacting with other systems.

That means the traditional security question:

"Can this application be compromised?"

needs to be accompanied by another:

"What can this AI system do if its instructions, context, identity, or tools are manipulated?"

That is a much more useful question for enterprise architecture teams.

It also explains why AI governance, application security, identity, data protection, and monitoring increasingly need to work together.

Final thoughts

AI agents can bring real value to enterprise workflows.

They can reduce repetitive work, connect systems, accelerate development, and help teams operate more efficiently.

But autonomy without boundaries is difficult to secure.

A mature enterprise AI implementation should therefore establish clear identities, tightly scoped permissions, controlled tool access, protected data flows, human approval for high-impact actions, and detailed monitoring.

The objective is not to prevent AI agents from acting.

It is to make sure they act within a boundary that the organization understands and can control.

For organizations working through the practical implications of recent AI security incidents and model evaluations, Infosprint's analysis of enterprise AI governance provides additional context on how these issues are developing across advanced AI systems and enterprise environments. Enterprise AI governance analysis by Infosprint

And for teams looking beyond governance policy toward the wider security architecture, the next step is connecting AI governance with appropriate cybersecurity solutions, identity controls, monitoring, and incident response.

The first production transaction corrupted the database.

The generative AI migration was supposed to be a success story.

The code compiled. The automated test suites passed. Every dashboard suggested the project was ready to scale.

Yet, the problem was hidden in what the Large Language Model (LLM) couldn’t see: decades of accumulated business logic buried across copybooks, shared memory structures, and dependencies spread throughout the application.

A single variable, governed by a COBOL REDEFINES clause and influenced by a flag set in an entirely different module, changed how critical transaction data was interpreted. The AI never knew that relationship existed. No compiler flagged it. No unit test caught it.

And that’s the reality many organizations discover when they attempt to modernize legacy systems with generative AI alone.

What Drives the Urgent Need for COBOL Modernization in Banking?

You already know the pressure points.

• The developers who understand your core banking COBOL — the ones who can read a 40-year-old batch job and explain why it branches the way it does — are in their sixties and seventies. Some have already left.

• The documentation, where it exists at all, often doesn’t match what the code actually does. In a lot of legacy banking environments, the code is the specification.

• Maintenance alone can consume the majority of an IT budget that should be funding digital channels, real-time payments, and broader banking digital transformation initiatives.

• Every quarter spent running parallel COBOL and modern systems is a quarter where competitors — fintechs and digitally native challengers — are shipping features your core can’t support.

The pressure is real. What’s changed in the last 18 months is how vendors are proposing to do it. Almost every COBOL-to-Java migration pitch you’ll hear now leads with generative AI.

“Our LLM-powered platform can convert your COBOL to Java in weeks, not years.”

Some of that is true. Some of it is exactly the kind of overconfidence that put a corrupted wire transfer into a test environment.

This is where legacy system modernization conversations need to get more precise. Not “should we use AI,” but “where exactly does AI help, and where does it quietly become the riskiest part of the project?”

Where generative AI actually breaks down in COBOL to Java conversion

To be clear: this isn’t an anti-AI argument. Generative AI genuinely accelerates parts of the AI COBOL-to-Java migration work, such as boilerplate generation, mapping COBOL identifiers to Java equivalents, handling packed decimal and EBCDIC encoding, and converting repetitive data-access patterns.

McKinsey’s research found GenAI reduces time on pattern-based coding tasks by 35–50% — but delivers less than 10% savings on high-complexity work.

Research from McKinsey, Gartner, and Advanced consistently puts the failure or non-completion rate for legacy modernization projects between 70% and 80%. Adding an LLM that produces misleadingly clean code on a failing process creates a new failure mode, not a solution.

The Financial and Regulatory Costs of Automated Migration Failures

If you’re weighing COBOL-to-Java migration cost against the promised 60-90% savings some AI-first vendors advertise, it’s worth running the math on the other side of the ledger too.

A migration that “passes” testing and then fails in production doesn’t just cost the rework. In a core banking context, it costs:

• Extended parallel-run periods :
  If your testing approach wasn’t accurate enough to catch the issue before cutover, you’re now running both systems longer than planned, which erodes most of the cost savings you migrated to capture

• Regulatory exposure :
  For institutions under frameworks like RBI’s IT outsourcing guidelines, Singapore’s TRM guidelines, OSFI’s tech risk expectations, or US federal banking regulators’ guidance, unexplainable AI-generated changes to core transaction systems are major concerns for examiners.

• Trust erosion internally :
  Once one AI-generated module causes a production incident, every subsequent module gets re-reviewed manually, which contradicts the purpose of using AI in the first place

The Hybrid Framework: How AI and human expertise actually divide the work

Human in the loop does not mean to use AI first then human checks for the errors. It’s a structured division of labor where each phase plays to a clear strength, AI’s speed and pattern recognition, paired with human judgment on the things that genuinely require it.

1. Discovery and dependency mapping
   This is the first and important step that AI skips but have a significant impact that links to success rate.

   Static and dynamic analysis reconstruct the full dependency graph: every copybook, every REDEFINES, every cross-module reference, and which code paths are actually live versus dormant.

   This typically takes one to two weeks for a system of meaningful size, and it produces the map that tells both the AI and the human reviewers where the real risk sits.

2. AI-assisted code generation — where the speed genuinely comes from
   Once we have this map ready the generative AI can work quickly on the 70-80% of the code base which exhibits clear patterns such as data access code, validation logic, file IO code, etc.

   This is legitimate, defensible automation. The AI isn’t guessing at hidden context anymore because the discovery phase already surfaced.

3. Human expert review on business-critical logic
   The remaining 20-30% — the parts of the system that encode genuinely novel, undocumented business rules — gets ... Read More.