DEV Community: Shruti Saraswat

Gemini context caching: why AI agent costs rise when context is repeated

Shruti Saraswat — Thu, 30 Jul 2026 05:30:14 +0000

A lot of AI cost conversations start in the wrong place. They start with the model.

Which model is cheaper?
Which one gives better output?
Which one has lower input cost?
Which one is faster?

Those questions matter, but they do not explain the full bill when you are building agentic workflows.

The more uncomfortable question is this:

How many times are you making the model read the same thing again?

That is where Gemini context caching becomes interesting.

Google’s Gemini API documentation says that in a typical AI workflow, the same input tokens may be passed to the model over and over. Gemini context caching is meant to optimize performance and costs when that happens. For Gemini 2.5 and newer models, implicit caching is enabled by default, and Google says cost savings are automatically passed on when requests hit caches.

That sounds like an infrastructure detail.

It is actually a product architecture detail.

Because if your AI workflow keeps repeating the same context at every step, the cost problem is not only the model. The cost problem is the workflow design.

The repeated context problem

Most AI agents are not one clean prompt and one clean answer.

They work in steps.

A support agent may read the customer message, the support policy, previous tickets, account details, product documentation, and tool results. Then it may call a tool, receive more information, ask the model again, draft a response, check another rule, and maybe ask the model again.

A CRM agent may read customer notes, sales rules, account history, enrichment data, and next-step instructions. Then it may classify the opportunity, update a field, draft a follow-up, and create a task.

A finance workflow may read policy, vendor data, invoice details, approvals, account rules, and past actions. Then it may extract fields, compare conditions, route the case, and prepare a decision.

The same blocks often appear again and again.

The system instructions appear again.

The policy appears again.

The product documentation appears again.

The customer record appears again.

The tool output appears again.

The cost grows because the model is not only answering. It is repeatedly reading the context needed to answer.

Why caching changes the way you think about AI cost

Caching is not just a discount button.

It rewards workflows where stable context is organized clearly.

If the same large policy text is used across many steps, it should not be treated like fresh context every time.
If the same product documentation supports repeated customer questions, it should be structured in a way that can be reused.
If the same instructions are part of every agent run, the workflow should separate stable instructions from changing user input.

This is where AI cost becomes less about “pick a cheaper model” and more about “stop sending the same information badly.”

A cheaper AI workflow usually comes from several small design choices working together:

keep stable context stable,
separate changing input from reusable background,
avoid sending entire documents when only one section is needed,
shorten tool outputs before the next model call,
stop retries from rereading the full context,
and measure the cost of the full workflow, not only one request.

The mistake: counting only the visible answer

The output is the part people notice.

The user sees the reply, the summary, the recommendation, or the generated report.

But the bill includes the work behind that answer.

If the agent needed five model calls, three tool calls, two retries, and a long context block each time, the cost is not represented by the final answer alone.

This is why AI features can feel cheap in a prototype and expensive in production.

In a prototype, one person tests one workflow a few times. The context is manageable. The usage is low. The hidden repetition does not hurt much.

In production, hundreds or thousands of users create repeated workflows every day. Small inefficiencies become normal behavior. A few extra context-heavy calls per workflow start to matter.

That is usually when teams realize the AI bill is not only a model bill.

It is a workflow bill.

A simple way to review an AI workflow cost

Before optimizing the model, look at the path.

Start with one actual customer workflow and trace what happens from the first request to the final action.

Ask what the model reads at each step. Does it need the full policy again? Does it need the whole customer history again? Does it need every tool result again? Does it need the entire conversation, or only the last few useful parts?

Then separate the context into three buckets.

Stable context

This is information that rarely changes during the workflow.

Examples include system instructions, product rules, policy text, feature documentation, tone guidelines, compliance instructions, and workflow boundaries.

Stable context is where caching can help, especially when many requests reuse the same background.

Session context

This is information that belongs to the current user or current workflow.

Examples include the customer message, selected account, recent ticket history, uploaded file, active case details, or tool output from this run.

This needs more care because some of it may be reused during the session, while some of it may become stale or unnecessary after one step.

Step-specific context

This is information needed only for one model call.

Examples include one extracted field, one decision question, one tool result, one short error message, or one approval state.

This should not turn into a long repeated block across the entire workflow.

Once these buckets are clear, the cost conversation becomes much easier.

What should be cached, shortened, or removed?

Not every context block should be cached.
Not every prompt should be shortened.
Not every output should be compressed.

The decision depends on what the workflow needs.

A stable policy used across many requests is a good candidate for reuse.
A long document that only matters for one answer may not need to stay in every step.
A tool result with one useful field should not be passed forward as a full JSON dump.
A retry should not automatically resend everything if only the final instruction changed.
A human review step should not force the next model call to reread irrelevant history.

The goal is not to starve the model of context. It is to stop feeding it context that does not help the next step.

Why this matters for SaaS products

SaaS products are full of repeated context.

Every customer has account rules.
Every workspace has permissions.
Every workflow has fixed instructions.
Every support process has policy.
Every CRM system has record history.
Every AI assistant has behavior guidelines.

If these blocks are sent poorly, the AI feature becomes more expensive than it needs to be. If they are structured well, the product can reuse stable context and keep each model call more focused.

That is why AI cost should be discussed during product design, not after the invoice arrives.

The economic question is not only:

Which model should we use?

It is:

What context does this workflow make the model reread, and how often?

Founder takeaway

Gemini context caching is a useful reminder that AI workflow cost is not only about the visible response.

The repeated context matters.

The retries matter.

The tool results matter.

The long instructions matter.

The number of model calls matters.

If an AI agent needs to complete a multi-step workflow, the team should design the context path as carefully as the tool path.

A good AI product does not only choose a model.

It decides what the model should read, what it should not read again, and what the product can reuse safely.

That is how AI cost becomes easier to understand before the bill becomes uncomfortable.

Sources

Google AI for Developers: Gemini context caching

https://ai.google.dev/gemini-api/docs/caching
Google AI for Developers: Gemini API pricing

https://ai.google.dev/gemini-api/docs/pricing
Anthropic Docs: Prompt caching

https://platform.claude.com/docs/en/build-with-claude/prompt-caching
Claude Platform release notes

https://platform.claude.com/docs/en/release-notes/overview

Google ADK 2.0 Workflows: your AI agent should not run the whole process

Shruti Saraswat — Tue, 28 Jul 2026 02:38:16 +0000

AI agents sound most exciting when they look independent.

They read the request.
They pick the tool.
They decide the next step.
They write the response.
They trigger the action.

That feels powerful.

It is also where things can get uncomfortable. Because a product workflow is not always something the model should invent while it is running.

A refund has rules.
A billing change has checks.
A CRM update needs the right account.
A support ticket needs context before it is closed.
An account action needs permission before anything changes.

This is why Google ADK 2.0 Workflows is worth paying attention to.

The update is not just another AI agent feature. It points to a better way of thinking about production AI: Let the product control the path. Let AI help where judgment is needed.

What Google ADK 2.0 Workflows is about

Google ADK 2.0 adds workflow support for building agents with more structure.

Instead of letting the model decide every step on its own, developers can define the route more clearly.

That route can include:

fixed software steps,
tool calls,
AI reasoning,
specialist agents,
human review,
and safe stopping points.

In plain English, this means the product can say:

This step always happens first.

This tool is only allowed here.

This action needs approval.

This error should stop the workflow.

This part is where AI should reason.

That is a much healthier way to build agentic products.

The problem with giving the agent everything

A lot of early agent designs start with too much freedom.

The agent gets a goal, a prompt, some tools, and a broad instruction to complete the job.

That might be fine for research, drafting, or internal experiments.

But customer-facing product flows are different.

If an agent is handling money, access, records, messages, files, or support actions, the product needs stronger boundaries.

The problem is not that the model is useless. The problem is that the model is being asked to do too many jobs at once.

It has to understand the user.

Pick the next step.

Remember the business rule.

Choose the tool.

Interpret the tool result.

Decide whether to continue.

Handle the failure.

And then decide when the job is done.

That is a lot to put inside one flexible system. Good software usually separates responsibilities. AI workflows should do the same.

The simple product lesson

Some parts of a workflow should be flexible. Some parts should not.

AI is useful when the input is messy.

For example:

understanding a customer complaint,
summarizing a long thread,
extracting details from a document,
classifying user intent,
drafting a reply,
or explaining a confusing case.

But the product should control steps that need consistency.

For example:

checking permissions,
validating required fields,
confirming account ownership,
checking refund policy,
blocking unsafe actions,
asking for human review,
saving audit records,
and stopping when required data is missing.

These are not places where the model needs freedom.

These are places where the product needs control.

A better way to design an AI agent workflow

Think of the AI agent as one part of the product, not the whole product.

A stronger workflow might look like this:

The customer sends a messy request.
The product collects the required account context.
The product checks permissions.
AI interprets the request.
The product checks the allowed path.
AI drafts the response or next step.
A human reviews sensitive cases.
The product completes only the approved action.
The system logs what happened.

That is still an AI-powered workflow.

But it is not a loose agent guessing its way through the business process.

It is a product flow with AI inside it.

That difference matters.

Example: a refund workflow

Imagine a customer asks for a refund.

A loose agent might read the message, check order history, decide whether the case sounds valid, and trigger a refund if it seems right.

That is risky.

A better workflow separates the jobs.

The product fetches the order.

The product checks the refund window.

The product verifies account ownership.

The AI reads the customer message and identifies the reason.

The product decides whether the case matches an approved path.

If the case is sensitive, a human reviews it.

Only then does the product complete the action.

The AI still helps.

But it does not own the whole process.

Why this matters for SaaS and AI products

More SaaS products are going to add agents.

Support agents.

Sales agents.

CRM agents.

Finance agents.

HR agents.

Operations agents.

Internal workflow agents.

Some will be impressive in the first version.

But the useful version is the one that can be trusted inside a product workflow.

That means the team should know:

what the agent can read,
which tools it can call,
which steps are fixed,
where AI is allowed to reason,
where human review happens,
what actions are blocked,
what happens when something fails,
and how the team can trace the workflow later.

That is the part many AI features miss.

They focus on what the agent can do.

The better question is what the product should allow it to do.

A practical rule

Here is a simple rule for product teams:

Use AI for unclear input.

Use software for clear rules.

Use humans for sensitive judgment.

That one line can prevent a lot of messy agent design.

If the task needs interpretation, AI can help.

If the task needs sequence, permission, or policy, the product should control it.

If the task affects money, access, trust, or customer outcomes, review should be part of the path.

Founder takeaway

Google ADK 2.0 Workflows is not only a developer update.

It is a signal about where AI product architecture is going.

The best AI agent is not always the one with more autonomy.

Sometimes the better agent is the one inside a clearer product path.

Because production AI is not about making the model responsible for everything.

It is about giving the model the right job, giving the product the right control, and making the whole workflow easier to trust.

Before adding more tools to an agent, ask this:

Which parts of this process should the AI never control on its own?

That is where the better design usually starts.

Sources

Google ADK 2.0 documentation - https://adk.dev/2.0/
Google Developers Blog: Why we built ADK 2.0 - https://developers.googleblog.com/why-we-built-adk-20/
Gemini Enterprise release notes - https://docs.cloud.google.com/gemini/enterprise/docs/release-notes

Software development agency for SaaS and AI products: how founders should evaluate before hiring

Shruti Saraswat — Sat, 25 Jul 2026 16:39:31 +0000

Hiring a software development agency is not just a hiring decision.

It is a product risk decision.

The wrong partner can write code and still leave the founder with an unclear system, weak architecture, missing documentation, fragile workflows, and no confidence after launch.

The right partner should make the product easier to understand, easier to maintain, easier to support, and easier to improve.

That matters even more when the product is not a simple website.

A SaaS platform has roles, billing, dashboards, permissions, customer data, workflows, alerts, integrations, and release pressure.
An AI product has data inputs, prompts, model routing, review steps, output quality, fallback behavior, cost control, and customer trust.
A CRM or business platform has operations, records, automations, access controls, reporting, and internal adoption.

So the question is not only:

Can this agency build the software?

The better question is:

Can this agency build the system in a way the business can rely on after launch?

The wrong way to choose an agency

Many founders choose a software agency by looking at surface signals:

Who quoted the lowest price?
Who promised the fastest timeline?
Who has the nicest portfolio image?
Who says they can build everything?
Who responds quickest to the first message?

Those signals are not useless.
But they are incomplete.

A low price can become expensive if the architecture has to be rebuilt.
A fast timeline can become slow later if the team skips product reasoning.
A polished portfolio can hide weak handover.
A confident pitch can still miss the operational details that decide whether the product survives customer use.

Software does not become valuable because it was built. It becomes valuable when users can depend on it and the team can keep improving it.

What founders should evaluate instead

A strong software development agency should be evaluated across the full product path.

Not only design.
Not only code.
Not only launch.

The full path includes scoping, architecture, user flows, backend logic, data model, integrations, cloud setup, security basics, QA, handover, documentation, monitoring, and post-launch improvement.

Here are the areas worth reviewing before hiring.

1. Product understanding before development

A reliable agency should not start by asking only for screens.
They should ask what the product has to achieve.

For example:

Who will use it?
What problem does it solve?
What workflow does it replace?
What data enters the system?
What decisions happen inside the product?
What should happen after launch?
What would make this product difficult to maintain later?

This matters because software scope without product context becomes task execution.

Founders do not need only task execution.
They need a product build that supports the business outcome.

2. SaaS architecture clarity

A SaaS product needs more than frontend screens and backend endpoints.
A serious build needs decisions around:

authentication,
user roles,
tenant structure,
billing,
dashboards,
data access,
audit history,
onboarding,
notifications,
admin controls,
file handling,
error states,
and release setup.

If an agency cannot explain how these parts will fit together, the founder may get a product that works in early testing but becomes difficult to operate later.

Ask the agency:

How will this product handle users, roles, data, billing, and future growth?

A good answer should be clear enough for a non-technical founder to understand.

3. AI workflow design

AI product development should not start with a model name.
It should start with the workflow.

A useful AI system needs:

data inputs,
context handling,
retrieval where needed,
prompt structure,
output format,
review states,
fallback behavior,
usage monitoring,
cost control,
and clear user experience.

The model is only one part of the system.

For example, an AI workflow for document processing should answer:

What documents can users upload?
What information should be extracted?
What should happen when the input is incomplete?
Who reviews the output?
What gets stored?
What can the user correct?
How is cost controlled?
What happens if the model output is uncertain?

An agency that treats AI as only a chatbot or model call may miss the product layer that makes the feature useful.

4. Cloud and release readiness

A product is not ready only because the code runs locally. The team should know how the product will be deployed, monitored, recovered, and maintained.

Cloud readiness includes:

environments,
CI/CD,
logs,
monitoring,
alerts,
storage,
workers,
queues,
backups,
access control,
error reporting,
and rollback planning.

This matters because founders often feel the difference after launch.

If no one can see what is failing, the product becomes hard to support.
If releases are manual and fragile, every update becomes stressful.
If monitoring is missing, customer issues become the first alert.

Ask the agency:

How will we know if something breaks, slows down, or needs attention after launch?

5. Business workflow fit

Custom software often fails when it copies a requested feature without understanding the workflow behind it.

A CRM is not just a contact table.
An operations platform is not just a dashboard.
An AI assistant is not just a chat box.
A marketplace is not just listings.
A SaaS product is not just authentication plus pages.

Good software maps the business workflow:

intake,
validation,
task routing,
approvals,
records,
actions,
notifications,
reports,
admin tools,
and customer-facing steps.

The agency should help uncover where the workflow needs structure before code is written.

6. Visibility during the build

A founder should not have to guess what is happening.

Strong delivery needs visible progress:

what was built,
what changed,
what is blocked,
what decision is needed,
what risk appeared,
what is next.

This is where trust is built. Not through vague reassurance. Instead through clear delivery rhythm.

An agency that communicates clearly gives the founder more control, even if the founder is not technical.

7. Quality and maintainability

Quality is not only visual polish.

Quality includes whether the next developer can understand the system.

A maintainable product usually has:

clean structure,
sensible naming,
predictable data flow,
reusable components,
clear API boundaries,
manageable state,
documented setup,
readable decisions,
and fewer hidden shortcuts.

Shortcuts may save time early. But they often create cost later.

Ask:

Will this product be easy to improve six months from now?

8. Handover and post-launch responsibility

A good agency should not disappear the moment the first version is shipped.

A founder needs to know:

where the code lives,
how the product is deployed,
how to access logs,
how to update content or settings,
how billing works,
how user roles work,
what known limitations remain,
and what should be improved next.

Post-launch clarity is part of delivery.
A product build is incomplete if the founder cannot operate it afterward.

9. Proof that matches the promise

Proof matters.

Not every proof point needs to be a large case study, but the agency should be able to show evidence that it has handled similar product complexity.

Look for:

shipped products,
client feedback,
repeat work,
public case studies,
clear service pages,
third-party reputation,
and proof of how the team thinks.

A portfolio screenshot is useful.
A clear explanation of the decisions behind the product is more useful.

How Ascent Innovate Software fits this standard

Ascent Innovate Software focuses on production-ready SaaS and AI products for founders and growing teams.

The work is not only about shipping features. The focus is on stable product foundations, AI workflows, cloud operations, product clarity, and software systems prepared for customer use.

Ascent’s public website lists 20+ builds delivered in past 1 year, 5 internal products, and 100% Upwork Job Success. It also describes service areas around MVP to production SaaS, AI integration and consultancy, production cloud and DevOps, and stabilizing or scaling existing products.

Those proof points matter because they connect delivery with trust.

But proof alone is not the point.

The more important part is how the work is approached:

clear scoping before development,
product reasoning before build decisions,
stable architecture,
visible delivery rhythm,
cloud and release readiness,
AI workflows with review and control,
and support for continuous improvement after the main build phase.

For founders, that is the agency standard worth looking for.

A practical hiring checklist

Before hiring any software development agency, ask these questions:

Can they explain the product workflow in simple language?
Can they show how the architecture will support future growth?
Can they build SaaS foundations such as auth, roles, billing, dashboards, and admin tools?
Can they design AI workflows with review, structure, output control, and fallback?
Can they set up cloud, deployment, monitoring, and release processes?
Can they communicate progress clearly during the build?
Can they hand over the system in a way your team can understand?
Can they show proof that matches the type of product you need?
Can they support improvement after launch?

If the answer is unclear, slow down before signing.

Founder takeaway

The best software agency for a founder is not the one that only writes code quickly.

It is the one that helps turn uncertainty into a product path.
A strong agency should help you understand what needs to be built, why it matters, how it will work, what risks exist, and how the product can keep improving after launch.

For SaaS and AI products, the build is only one part.
The system has to be reliable, maintainable, understandable, and ready for customer use.

That is the standard worth hiring for.

References

ICO AI risk toolkit: why AI teams need a data map before another model

Shruti Saraswat — Fri, 24 Jul 2026 06:04:07 +0000

Most AI governance problems do not begin with a dramatic failure.

They begin with a small missing answer.

Which data does this feature use?
Where did it come from?
Which vendor touches it?
Which model processes it?
Is the output only a suggestion?
Can a human override it?
Can the data be removed later?
Who owns the review?

When a team cannot answer those questions clearly, the AI feature may still work.

But it becomes harder to explain, harder to improve, harder to audit, and harder to trust.

That is the useful signal from the UK ICO’s AI and data protection risk toolkit.

The toolkit is designed to help organisations reduce risks to people’s rights and freedoms caused by their AI systems. The ICO’s broader AI audit framework also focuses on areas such as governance and accountability, transparency, and third-party contracts.

For software teams, the practical takeaway is simple:

Before adding another model, map the AI workflow that already exists.

The hidden problem: AI features spread faster than AI records

AI features rarely stay in one clean box.

A team starts with one model call.

Then it adds a vector database.

Then a vendor API.

Then a support workflow.

Then logs.

Then evaluation data.

Then analytics.

Then a fallback model.

Then a human review queue.

Then customer-facing explanations.

Then a new team uses the same data for a different purpose.

Nothing looks messy on day one.

But after a few months, the company may not have a single clear view of how the AI system actually works.

The code may know.

The product team may know part of it.

The data team may know another part.

The legal or compliance team may see only the policy.

Support may see the customer questions.

Leadership may see only the feature name.

That gap becomes the governance problem.

Why a data map matters

An AI data map is not only a compliance document.

It is a product operating tool.

It helps the team understand:

what data enters the AI workflow,
where that data came from,
what the AI system does with it,
which vendors or models process it,
what output reaches the user,
what decision the output may influence,
where human review happens,
how the system is monitored,
and how data can be corrected, excluded, or removed.

Without this map, the team may keep adding AI capabilities on top of an unclear foundation.

That is how small risks become product-wide risks.

The practical AI data map

A useful AI data map should be simple enough for product, engineering, privacy, support, and leadership to read.

It does not need to be a 70-page document.

It needs to answer the questions the team will be asked later.

1. The data source

Start with the data.

For each AI feature, list the data sources.

Examples:

customer messages,
uploaded files,
CRM records,
product activity logs,
public web pages,
internal documents,
support tickets,
call transcripts,
analytics events,
workspace data,
or third-party datasets.

Then record the basics:

where it came from,
why it is needed,
whether it contains personal data,
whether it contains sensitive data,
whether the user or customer expects this use,
and whether the data can be reduced before processing.

The goal is to stop vague phrases like “uses customer data.”

That phrase is not enough.

A useful map says exactly what kind of customer data, from which system, for which AI task.

2. The model or vendor

Next, list what processes the data.

This may include:

hosted model APIs,
internal models,
open-source models,
embedding models,
rerankers,
transcription tools,
moderation tools,
OCR systems,
vector databases,
analytics tools,
or agent frameworks.

For each one, the team should know:

who provides it,
what data is sent,
whether data is stored,
whether it is used for training,
where processing happens,
what contract or privacy terms apply,
and what fallback exists if the vendor changes.

This matters because many AI features are not one model.

They are a chain of services.

If the chain is not mapped, vendor risk becomes invisible.

3. The AI task

The map should describe what the AI system actually does.

Not in marketing language.

In workflow language.

For example:

summarizes a support thread,
extracts fields from a document,
ranks candidate records,
recommends a next action,
drafts a reply,
flags risky activity,
generates a customer answer,
routes a ticket,
classifies user intent,
or searches internal knowledge.

This makes the system easier to review.

A summarization tool, a decision-support tool, and an automated action tool do not need the same controls.

4. The output destination

Where does the AI output go?

This is one of the most important parts of the map.

An output may be shown to:

a customer,
an employee,
a manager,
a support agent,
an admin,
an internal dashboard,
a downstream workflow,
another AI system,
or an external system.

The risk changes depending on where the output lands.

A draft shown to an internal reviewer is different from an answer sent directly to a customer.

A risk label shown in a dashboard is different from a label that changes access or priority.

The map should show the destination clearly.

5. The decision impact

Not every AI output is a decision.

But many outputs influence decisions.

The team should ask:

Does this affect access?
Does it affect money?
Does it affect customer support priority?
Does it affect hiring or workload?
Does it affect account status?
Does it affect visibility?
Does it affect what a user is allowed to do?
Does it affect what a person is told?

If the output influences something important, the workflow needs stronger review.

This is where a data map becomes more than documentation.

It becomes a product safety tool.

6. The human review point

The map should show where a person can review, correct, or stop the AI output.

A vague note like “human review available” is not enough.

The map should define:

who reviews,
when they review,
what they can change,
what information they see,
what happens if they disagree,
and whether the user can request review.

This matters because human review only helps when it is part of the actual workflow.

7. The removal or correction path

AI systems need a way to change.

A customer may delete data.

A source may become unreliable.

A document may be outdated.

A vendor may change terms.

A model may be replaced.

A user may challenge an output.

A regulator, buyer, or internal leader may ask how data is removed from active use.

The team should know:

how to remove a source,
how to update an index,
how to correct wrong data,
how to exclude certain records,
how to retrain or reprocess where needed,
and who approves the change.

If the team cannot change the data path, the AI feature becomes harder to govern over time.

The mistake is treating the AI feature as one thing

Most AI features are not one thing.

They are a chain.

Data source → preprocessing → model or vendor → storage → retrieval → output → human review → user action → logging → monitoring.

If the team only reviews the model, it misses the system.

If the team only reviews the policy, it misses the workflow.

If the team only reviews the output, it misses the data path.

The useful review is the full path.

A simple field note for product teams

Before adding another model, create one page for the AI feature.

The page should answer:

What data enters the workflow?
Where does it come from?
Which model or vendor processes it?
What does the AI system do?
Where does the output go?
What decision can it influence?
Where can a person review it?
How can data be corrected or removed?
Who owns the workflow?

That one page will not solve everything.

But it will reveal what the team actually understands.

And that is often the first step toward better governance.

Founder takeaway

AI governance does not start with a long policy.

It starts with a clear map.

A team should be able to point to an AI feature and explain:

the data it uses,
the model or vendor involved,
the output it creates,
the decision it may influence,
the review step,
the correction path,
and the owner.

If the team cannot map the workflow, it probably cannot govern the workflow.

Before adding the next AI feature, map the one already in production.

That may be the most useful governance work a product team can do.

Sources

ICO: AI and data protection risk toolkit

https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/ai-and-data-protection-risk-toolkit/
ICO: Artificial intelligence audit framework

https://ico.org.uk/for-organisations/advice-and-services/audits/data-protection-audit-framework/toolkits/artificial-intelligence/

EU AI Act workplace AI rules: when productivity tools start shaping people decisions

Shruti Saraswat — Fri, 24 Jul 2026 05:17:22 +0000

AI inside workplace software can look harmless at first.

It ranks candidates.
It summarizes interviews.
It scores employee activity.
It recommends task assignments.
It flags performance patterns.
It highlights people who may need attention.
It drafts feedback.

Each of those features can sound like productivity.

But the consequence changes when the output affects a person’s work.

A recommendation inside a hiring tool can shape who gets interviewed.

A productivity score can shape who gets questioned.

A task-allocation system can shape who receives better opportunities.

A performance signal can shape promotion, pay, workload, or termination discussions.

That is why workplace AI deserves a different product review.

The European Commission lists AI tools for employment, worker management, and access to self-employment as high-risk examples under the EU AI Act. These include areas such as recruitment and CV sorting. The EU AI Act Service Desk’s Annex III page also includes systems used for recruitment, targeted job ads, filtering applications, and evaluating candidates.

Reuters recently reported that workplace AI may still be high-risk even when a human makes the final decision, if the AI output materially influences decisions such as hiring, promotions, task allocation, or performance monitoring.

For software teams, the practical lesson is simple:

If AI influences someone’s work life, it needs more than a productivity label.

Why this matters

Workplace AI often enters quietly.

Not as a major automated decision system.

Not as a replacement for managers.

Not as a scary surveillance tool.

It usually starts as something small:

help recruiters shortlist faster,
help managers see workload patterns,
help teams assign tasks better,
help HR review performance signals,
help operations detect low productivity,
help support leaders evaluate response quality.

Those use cases may be useful.

But they also create a consequence path.

The person affected may not see the model.

They may only see the outcome.

No interview.

Lower ranking.

More difficult tasks.

Less visibility.

A poor performance note.

A delayed promotion.

A warning from a manager.

That is where workplace AI becomes a trust issue, not only an internal tooling issue.

The mistake teams make

The common mistake is reviewing the tool as if it only helps the company.

That is too narrow.

A workplace AI tool also affects the person being evaluated, ranked, scheduled, monitored, or compared.

So the product review should not stop at:

Does it save time?
Is the output useful?
Does the manager like it?
Does it integrate with HR software?

The better review asks:

Who is affected by the output?
What decision may follow?
Can the person understand the signal?
Can a manager override it?
Can the company explain it later?
Is the tool measuring what actually matters?
Could the tool quietly reward or punish the wrong behaviour?

The 7-check workplace AI review

1. Consequence mapping

Start by writing down what the AI output can influence.

Does it affect:

hiring,
interview selection,
candidate ranking,
task assignment,
shift allocation,
performance review,
promotion,
compensation,
contract renewal,
termination,
disciplinary action,
or manager perception?

This matters because the same feature can be low-risk in one workflow and high-impact in another.

A summary tool used for internal notes is different from a scoring tool used to shortlist candidates.

Check:

What could happen to a person because this AI output exists?

2. AI influence level

A product does not need to make the final decision to influence the final decision.

If AI ranks, filters, scores, flags, compares, or recommends, it may already shape the outcome.

This is especially important in workplace tools because human reviewers may trust the system too much.

If a recruiter sees a ranked list, the lower-ranked candidates may receive less attention.

If a manager sees a risk score, that employee may be treated differently.

If a task system assigns difficult work repeatedly, the person’s growth and evaluation may change.

Check:

Is AI only showing information, or is it steering the decision?

3. Data quality

Workplace data can be messy.

Activity logs do not always equal effort.

Keyboard activity does not equal productivity.

Response speed does not equal quality.

Meeting time does not equal impact.

Ticket volume does not equal customer value.

A model trained on weak signals may create confident but unfair conclusions.

Teams should review:

source data,
missing context,
role differences,
team differences,
historic bias,
outliers,
data freshness,
and whether the signal actually fits the decision.

Check:

Are we using data that truly supports the workplace decision?

4. Fairness across roles

Workplace AI can compare people who should not be compared directly.

A salesperson, designer, engineer, recruiter, support agent, and operations manager create value differently.

Even inside one function, work conditions may differ.

A support agent handling complex enterprise cases may close fewer tickets than someone handling simple requests.

An engineer working on deep infrastructure may show fewer visible commits than someone fixing small UI bugs.

If the AI system ignores role context, it may reward visible activity over meaningful contribution.

Check:

Does the system understand role context before comparing people?

5. Human review that means something

“Human review” should not be a checkbox.

A meaningful human review should define:

who reviews the AI output,
when they review it,
what extra context they must check,
what they can override,
how disagreement is recorded,
and whether the person affected can respond.

If the reviewer simply accepts the AI output most of the time, the workflow may still behave like automation.

Check:

Can a person challenge, correct, or override the AI output before it affects someone?

6. Transparency to affected people

People should not be evaluated by hidden systems they do not understand.

That does not mean every model detail must be shown.

But affected people should know:

AI is being used,
what kind of data it considers,
what the output is used for,
who sees the output,
whether it affects decisions,
and how they can question it.

Clear communication builds trust.

Hidden scoring creates anxiety.

Check:

Would the person affected understand how AI is being used in the workflow?

7. Audit and correction path

Workplace AI needs a way to investigate mistakes.

The team should be able to answer:

what data was used,
what output was produced,
who reviewed it,
what decision followed,
whether the output was overridden,
whether the person challenged it,
and what changed afterward.

Without an audit path, the company may not be able to explain a harmful outcome.

Without a correction path, the same mistake may repeat.

Check:

Can the team trace, correct, and improve the system after a bad outcome?

A simple workplace AI decision model

Before shipping workplace AI, classify the feature into one of four levels.

Level 1: Assistive

AI helps people work faster but does not evaluate anyone.

Examples:

summarize a policy document,
draft a meeting note,
organize HR knowledge-base content.

Governance need: basic review, accuracy checks, data privacy controls.

Level 2: Evaluative

AI creates a signal about a person, team, candidate, or worker.

Examples:

candidate ranking,
performance scoring,
productivity signal,
engagement risk flag.

Governance need: data-quality review, fairness checks, transparency, human review.

Level 3: Decision-supporting

AI output influences an employment-related decision.

Examples:

shortlist candidates,
recommend promotion readiness,
suggest disciplinary review,
influence shift or task allocation.

Governance need: stronger documentation, meaningful oversight, audit trail, affected-person communication.

Level 4: Decision-driving

AI output strongly shapes or triggers the final outcome.

Examples:

reject candidates automatically,
reduce access,
suspend a worker,
change pay or workload,
trigger termination review.

Governance need: high-impact review, strict human control, explanation, appeal or challenge path, ongoing monitoring.

The point is not to block workplace AI.

The point is to stop treating all workplace AI as simple productivity tooling.

Founder takeaway

Workplace AI can save time.

But when it affects people, time saved is not the only thing to measure.

A product team should also measure:

whether the signal is fair,
whether the data is meaningful,
whether humans can correct the output,
whether affected people understand the system,
and whether the company can explain what happened later.

The product question is not:

Can AI help managers decide faster?

It is:

Could the person affected understand and challenge the outcome if needed?

That is where workplace AI becomes a governance decision.

A good workplace AI feature does not only help the company move faster.

It protects the people inside the workflow from unclear, unfair, or unchallengeable outcomes.

Sources

AI decision automation: 7 checks before your product lets AI decide

Shruti Saraswat — Wed, 22 Jul 2026 10:47:34 +0000

AI can speed up decisions.

That does not mean every decision should be automated.

A product may use AI to score a request, rank a lead, suggest a next action, flag risk, approve access, reject a claim, route a support ticket, or change what a user is allowed to do.

Some of those uses are low-risk.

Some affect money, access, eligibility, trust, or customer rights.

That is where the product decision becomes more serious.

The useful signal this week comes from Australia’s new AI governance direction. The Australian government is setting up an Office of AI to coordinate a new national AI standard, and recent reporting says stricter rules are being prepared for automated decision-making in government services, with attention to fairness, accuracy, transparency, and safety.

For software teams, the practical lesson is simple:

Do not treat every AI output as the same kind of decision.

The product should clearly separate:

AI suggestions,
AI-assisted decisions,
automated decisions,
human approvals,
and user appeals.

Why this matters

Most AI product risk does not appear because the model gave an answer.

It appears because the product treated that answer as a decision.

There is a big difference between:

AI suggests a support priority,
AI automatically closes a customer complaint,
AI drafts a risk note,
AI denies a user request,
AI flags a record for review,
AI changes an account permission.

The same model output can be harmless in one workflow and high-impact in another.

That is why “we use AI” is not enough detail.

A product team needs to know what role AI plays in the decision path.

The decision ladder

Before automating any AI-driven workflow, place it on a decision ladder.

Level 1: AI organizes information

The AI sorts, groups, summarizes, labels, or highlights information.

Example:

summarizing a support thread,
grouping feedback themes,
extracting fields from a document,
sorting tickets by topic.

This is usually lower risk because AI is helping humans understand information.

Level 2: AI recommends a next step

The AI suggests what might happen next, but does not execute the outcome.

Example:

recommending a reply,
suggesting a fraud review,
proposing a retention offer,
highlighting a risky transaction.

This needs review because users may trust the recommendation too much.

Level 3: AI prepares the action

The AI drafts or prepares the action, but a human or user confirms before it happens.

Example:

drafting an account update,
preparing a refund note,
filling a form,
creating a decision summary.

This can be useful when the confirmation step is clear.

Level 4: AI decides automatically

The AI or automated system makes the decision without human approval in each case.

Example:

rejecting an application,
suspending an account,
denying access,
changing eligibility,
approving a financial or operational action.

This is where stronger governance is required.

Level 5: AI decides with appeal rights

The product allows automation, but the affected user can understand, challenge, or request review.

Example:

automated moderation with appeal,
automated risk flags with human review,
automated eligibility decisions with a documented review path.

This is usually the safer direction for high-impact workflows.

The 7-check AI decision automation review

1. Decision impact

Start by asking what the decision changes for the user.

Does it affect:

money,
account access,
service eligibility,
pricing,
ranking,
visibility,
workload assignment,
support priority,
hiring,
healthcare,
finance,
legal status,
or customer trust?

If the answer is yes, the system needs more than normal feature testing.

Check:
Could this AI output affect a person’s access, money, rights, or important opportunity?

2. AI role

Define exactly what AI is doing.

Is it:

summarizing,
recommending,
ranking,
flagging,
drafting,
approving,
rejecting,
escalating,
or changing a record?

This is where vague product language creates risk.

“AI-powered decisioning” is not precise enough.

The team should name the role in the workflow.

Check:
Is AI informing the decision, preparing the decision, or making the decision?

3. Human checkpoint

If a decision is high-impact, decide where human review belongs.

Not every AI use needs manual review. But high-impact AI workflows often need a meaningful checkpoint before the outcome reaches the user.

Good checkpoints are specific:

review before account suspension,
review before eligibility denial,
review before data export,
review before financial adjustment,
review before a decision is sent to the customer.

Weak checkpoints are vague:

“human in the loop”
“manual review if needed”
“team can override”

Those phrases sound safe, but they may not describe an actual workflow.

Check:
Where does a person approve, override, or stop the AI-driven outcome?

4. Explanation

Users and internal teams need an explanation they can understand.

That does not mean exposing model internals.

It means explaining:

what information was considered,
what rule or workflow applied,
what the AI contributed,
what the final outcome means,
and what the user can do next.

If the product cannot explain the decision in plain language, the decision may be too opaque for the workflow.

Check:
Can the product explain the decision without hiding behind the model?

5. Appeal or review path

For decisions that affect users meaningfully, the product should have a challenge path.

That may include:

request review,
provide missing information,
correct inaccurate data,
talk to support,
escalate to a specialist,
receive a human-reviewed outcome.

This matters because AI systems can be wrong.

They can also rely on incomplete, stale, or biased input data.

A user should not be trapped by an automated decision with no path forward.

Check:
Can the user challenge the outcome or ask for review?

6. Audit trail

The team should be able to reconstruct what happened.

A useful audit trail records:

input source,
AI output,
confidence or uncertainty signal where available,
human reviewer,
final decision,
override reason,
timestamp,
version of the model or rules,
and customer-facing explanation.

Without logs, the team may not be able to improve the system or answer complaints.

Check:
Can the team trace how this decision happened later?

7. Drift and quality monitoring

An AI decision workflow can become worse over time.

The input data may change.

Customer behavior may shift.

A policy may update.

A model may behave differently after an update.

A team may start using the feature in a new context.

Monitor:

error rate,
override rate,
appeal rate,
complaint themes,
bias indicators,
false positives,
false negatives,
and workflow completion.

Do not measure only automation volume.

Measure decision quality.

Check:
How will the team know the decision workflow is getting worse?

A simple decision rule

Use AI differently based on the consequence.

Low-impact workflow

AI can organize, summarize, classify, or suggest.

Examples:

sorting internal notes,
grouping feedback,
drafting a support reply.

Medium-impact workflow

AI can prepare, but a human or user should confirm.

Examples:

account update,
escalation path,
customer communication.

High-impact workflow

AI should assist, but the product needs human review, explanation, audit trail, and appeal path.

Examples:

denying access,
suspending accounts,
determining eligibility,
financial decisions,
sensitive data decisions.

The product should not jump from suggestion to decision simply because automation is possible.

Founder takeaway

AI automation is useful when it removes repetitive work.

It becomes risky when the product quietly lets AI decide outcomes that customers care about.

The founder question is not:

Can AI make this faster?

It is:

Should AI decide this, or only prepare it for review?

That distinction can protect the product from trust issues later.

A good AI workflow does not only produce an answer.

It shows where the answer becomes a decision, who can review it, and how a user can challenge it.

Sources

Web scraping for AI training is not free data: 7 privacy checks before collection

Shruti Saraswat — Tue, 21 Jul 2026 11:29:19 +0000

Web scraping often looks cheap from the outside.

A crawler collects pages.
A dataset grows.
A model gets more examples.
The product team gets more material to train, test, classify, summarize, or evaluate.

But when scraped data contains personal data, the cost is not only infrastructure.

There is a privacy cost.

There is a documentation cost.

There is a cleanup cost.

There is a review cost.

That is the useful signal from the EDPB’s July 2026 draft guidelines on web scraping in the context of generative AI.

The European Data Protection Board says GDPR applies to web scraping when it includes personal data processing operations, including collection, storage, organisation, and retrieval. The Board also points teams toward questions around legal basis, purpose limitation, transparency, accuracy, data minimisation, and special-category data.

For software teams, the practical lesson is simple:

Scraped data is not automatically usable just because it is publicly visible.

Why this matters for AI teams

A lot of AI work depends on data that looks available.

Product reviews. Public profiles. Forum posts. Help pages. Job listings. Marketplace entries. Documentation pages. Social content. Website text. Support examples. Public code comments. Knowledge-base content.

Some of that data may be harmless to collect and use.

Some may include personal data.

Some may include sensitive personal data.

Some may include inaccurate, outdated, or copied information.

Some may be visible publicly but still not appropriate for the AI purpose the team has in mind.

That is where the economics change.

The team may think it is collecting “free training material.” But if that collection creates privacy review, filtering, deletion, transparency, accuracy, and governance work, the dataset is not free.

It has operating cost.

What changed

On 8 July 2026, the EDPB announced draft guidelines on web scraping in the context of generative AI and guidelines on anonymisation. The web-scraping guidance is open for public feedback until 30 October 2026.

The EDPB describes web scraping as large-scale automated data extraction that often happens without people being aware and may create risks for personal data protection.

It also clarifies that GDPR applies when scraping includes personal data processing operations.

That matters because AI teams cannot treat the act of scraping, storing, cleaning, and retrieving personal data as a neutral technical step.

It becomes data processing.

And data processing needs a lawful and documented basis.

The hidden cost in scraped data

The obvious cost is crawling, storage, and processing.

The less obvious cost sits around the dataset.

Teams may need to answer:

Why was this data collected?
What lawful basis supports the use?
Which sources were used?
When was it collected?
Was personal data included?
Was special-category data included?
Was inaccurate data removed?
Was the data minimised?
Can data be deleted or excluded later?
Can the team explain the purpose?

These questions take time.

If the team answers them late, the cost is higher.

That is why the best time to design the data process is before collection starts.

The 7-check scraping readiness review

1. Purpose before collection

Do not start with “collect everything and decide later.”

Start with the task.

Is the data needed for model training, evaluation, retrieval, classification, moderation, quality testing, benchmarking, or product analytics?

Each purpose may need a different level of review.

If the purpose is vague, the dataset will grow beyond the product need.

Check:
Can the team explain the specific AI task the scraped data supports?

2. Source reliability

The EDPB recommends scraping only from reliable sources, recording the timestamp, and validating data before using it for AI training.

That is an important practical point.

A model trained or evaluated on unreliable data can produce worse outputs, not better ones.

Teams should record:

source URL,
collection date,
collection method,
source type,
update frequency,
known quality issues,
and whether the data is likely to include personal information.

Check:
Do we know where the data came from and when it was collected?

3. Personal-data filter

Public text can still include personal data.

That may include names, emails, usernames, work history, photos, location references, contact details, comments, complaints, account identifiers, or anything that can identify a person directly or indirectly.

The team should filter before the data enters training, evaluation, or indexing workflows.

This can include:

removing obvious identifiers,
detecting contact details,
excluding profile pages,
excluding private or semi-private contexts,
reducing unnecessary fields,
and retaining only what is needed for the stated purpose.

Check:
What personal data might enter the dataset, and can we reduce it before use?

4. Special-category risk

The EDPB reminds teams that processing special categories of personal data is generally prohibited unless both a GDPR Article 6 lawful basis and an Article 9(2) exception apply.

That matters because scraped data may accidentally include health, political views, religion, trade-union membership, biometric data, sexual orientation, or other sensitive categories.

Even if the team did not intend to collect it, the risk can still appear in large-scale scraping.

Check:
Could the dataset include sensitive personal data, even by accident?

5. Transparency plan

The EDPB says particular attention should be paid to transparency. It also notes that depending on how processing is designed, personal notice may not always be required if it is impossible or would require excessive effort.

This means teams still need a transparency position.

For product teams, that may include:

privacy notice updates,
dataset descriptions,
source categories,
opt-out or objection channels where applicable,
internal documentation,
and support-ready language.

Transparency is not only a legal page.

It is the ability to explain what the product is doing with data.

Check:
Can we explain the data source and purpose without hiding behind vague language?

6. Data minimisation

A large dataset is not automatically a better dataset.

If the task only needs short examples, do not store full pages.

If the model only needs public documentation, do not collect comments.

If evaluation only needs categories, do not keep identifiers.

Data minimisation means collecting and retaining only what is necessary for the purpose.

This can reduce privacy risk, storage cost, review burden, and future cleanup.

Check:
Are we keeping data because it is needed, or because it was easy to collect?

7. Removal and exclusion path

AI datasets need a way to change.

A source may become unreliable. A person may object. A site may update its policy. The team may discover sensitive data. The product purpose may change.

The team should be able to remove or exclude data from future use.

That does not mean every system can perfectly forget every past influence in a model. But teams should still design practical controls:

dataset versioning,
source exclusion lists,
deletion workflows,
retraining or re-indexing rules,
audit logs,
and clear ownership for data removal decisions.

Check:
If this source becomes unsuitable, can we remove it from the active data workflow?

A simple decision model

Before scraping data for an AI workflow, place it into one of four buckets.

Safe to use with basic records

Data that is non-personal, reliable, and directly tied to the AI task.

Example: public technical documentation used for retrieval.

Use only after filtering

Data that may contain personal details but can be reduced safely.

Example: forum text after removing identifiers and irrelevant fields.

Use only with stronger review

Data that may contain sensitive context, user-generated content, profiles, or mixed personal data.

Example: public social posts, support discussions, community profiles.

Do not use for this purpose

Data that is too sensitive, unreliable, unrelated, or impossible to govern.

Example: scraped personal profiles for unrelated AI training.

The goal is not to block useful AI work.

The goal is to stop treating every public page as equally usable.

Founder takeaway

Scraping can make AI work feel faster at the beginning.

It can also create hidden work later.

The important question is not only:

Can we collect this data?

It is:

Can we justify, minimise, validate, explain, and remove it if needed?

That is where the cost of AI data becomes visible.

A small, governed dataset can often be more useful than a large dataset nobody can explain.

Sources

Android AI interoperability: 7 data-access checks before your app works with AI assistants

Shruti Saraswat — Mon, 20 Jul 2026 05:15:27 +0000

AI assistants are moving closer to the operating system.

That changes the privacy decision for app teams.

It is no longer only about what your app stores, what your backend processes, or what your own AI feature can access. The next question is what happens when another AI assistant can search, retrieve, interpret, or act on data your app makes available on the device.

That is the useful signal behind the European Commission’s July 2026 DMA guidance to Google.

The Commission’s Android AI measures require Google to provide effective interoperability for certain Android features relevant to AI services. The measures cover areas such as contextual invocation, centralised access to on-device app data, context-aware intelligence, structured app actions, on-device model access, and background execution.

In simple terms, rival AI assistants may need deeper Android access to compete fairly.

For software teams, the practical question is this:

If AI assistants can reach deeper into the device, what should your app intentionally share, protect, and explain to users?

What changed

On July 16, 2026, the European Commission published guidance under the Digital Markets Act relating to Google Android AI interoperability and Google Search data sharing.

The Android decision focuses on how third-party AI services should receive effective interoperability with Android features that Google’s own AI services can use.

The Commission’s published measures include several categories:

invocation features, such as contextual launch and hotword-related access,
centralised access to apps’ data stored on-device,
context-aware intelligence,
structured on-device integrations,
system-level on-device models,
hardware resources for on-device model operation,
and background execution.

One important section discusses centralised access to app data stored on-device. The measure refers to access to data that apps choose to share in a centralised manner, allowing cross-app search and retrieval.

That phrase matters:

apps choose to share.

This is where product teams enter the governance conversation.

Why this matters for app and SaaS teams

Many software products already live across mobile apps, web dashboards, backend APIs, notifications, support workflows, and AI features.

If AI assistants become more integrated into the operating system, users may expect those assistants to help them find information, summarize activity, trigger actions, or move between apps.

That can be useful.

But it also raises questions:

Which app data should be searchable by an assistant?
Which data should stay inside the app?
Which actions can an assistant trigger?
What should require the app UI?
How should users know what is being shared?
What happens when multiple assistants request similar access?
Can users change the sharing level later?

These are not only technical permissions.

They are product governance decisions.

The data-access problem

A product may hold different kinds of data:

public content,
user-created notes,
private messages,
customer records,
financial information,
health information,
internal business data,
notifications,
location signals,
saved preferences,
task history,
and support interactions.

Not all data belongs in the same sharing model.

Some information may be safe and useful for AI-assisted search.

Some may be useful only with explicit user action.

Some should never leave the product boundary except through carefully designed flows.

The mistake is treating app data as one category.

It is not.

The 7-check Android AI interoperability review

1. Data category

Start by classifying what the app stores on-device.

Separate:

public content,
user-owned content,
account data,
sensitive records,
transactional data,
notifications,
settings,
and data that belongs to a business or workspace.

The goal is not to slow the product team.

The goal is to avoid exposing different data types through one broad integration path.

Review question:
What kind of data could an assistant discover or retrieve?

2. User intent

AI assistant access should follow user intent, not only technical availability.

For example, a user may want an assistant to find a document title, but not read all document contents. A user may want a calendar summary, but not expose private notes. A user may want an action shortcut, but not allow background changes.

Teams should decide which access requires:

user opt-in,
in-the-moment confirmation,
app-level permission,
workspace admin approval,
or no sharing at all.

Review question:
Did the user clearly choose this data-sharing behavior?

3. Action boundary

Search and action are different.

Letting an assistant find information is not the same as letting it change something.

A product should distinguish between:

search,
retrieval,
summarization,
drafting,
navigation,
data update,
transaction,
deletion,
submission,
or external send.

An assistant that can read a task list should not automatically be able to close tasks, update account records, send messages, or trigger billing changes.

Review question:
Can the assistant only read, or can it also act?

4. Sensitive workflow protection

Certain workflows should require stronger control.

Examples include:

billing,
account deletion,
permission changes,
data export,
customer record updates,
legal or compliance content,
medical or financial information,
identity verification,
and admin actions.

Even if an assistant can help users reach those areas faster, the final step may still need app-owned confirmation.

Review question:
Which workflows should stay inside the app experience?

5. Visibility to users

Users should understand when external AI services can use app data or trigger app actions.

This does not mean burying people in permission text.

It means making the permission meaningful:

what is shared,
why it is shared,
which assistant can use it,
what actions are allowed,
and how to turn it off.

The product should not make users guess what the assistant can see.

Review question:
Can a normal user understand what the assistant is allowed to do?

6. Revocation and change

Consent and permissions should not be permanent by default.

Users may change their mind. A company may switch assistant providers. A workspace admin may restrict access. A regulation may require tighter control. A feature may change.

Teams should design revocation clearly:

user-level off switch,
workspace-level controls,
admin policy,
audit trail,
permission expiry,
and fallback behavior when access is removed.

Review question:
Can access be changed or removed without breaking the product?

7. Audit and support

When AI assistants interact with app data, support teams may need to answer new questions.

A user may ask:

Why did the assistant show this?
What data was used?
Which app allowed it?
Did an action happen?
Can I reverse it?
How do I stop this next time?

Teams should plan basic audit trails and support language before launch.

Review question:
Can the team explain what happened if a user questions an assistant action?

A simple implementation model

A practical model is to separate app data and actions into four tiers.

Tier 1: Safe discovery

Data that can be found or surfaced without exposing sensitive content.

Examples:

public help pages,
feature names,
document titles,
app shortcuts,
non-sensitive metadata.

Tier 2: User-approved retrieval

Data that may be retrieved only when the user clearly asks.

Examples:

personal notes,
task lists,
saved items,
account-specific summaries.

Tier 3: App-confirmed actions

Actions where the assistant can prepare the step, but the app should confirm before completion.

Examples:

updating a record,
sending a message,
exporting a file,
changing a setting.

Tier 4: Protected workflows

Areas that should stay behind app-owned controls.

Examples:

billing changes,
permission changes,
account deletion,
sensitive data exports,
regulated data.

This model keeps the product useful without treating assistant access as all-or-nothing.

Founder takeaway

AI interoperability may create better user experiences.

But deeper assistant access also makes data governance more important.

For founders, the decision is not only whether to support AI assistants.

It is whether the product can clearly answer:

what data can be discovered,
what data can be retrieved,
what actions can be triggered,
what needs confirmation,
what remains protected,
and how users can change their choice.

The useful product question is not:

Can an assistant use our app data?

It is:

Should it, under which conditions, and with what user control?

That is where AI interoperability becomes a product governance decision.

Sources

The Developer Tool Trust Checklist: 7 checks before a plugin reaches your pipeline

Shruti Saraswat — Fri, 17 Jul 2026 05:50:52 +0000

Most teams review application code before it reaches production.

Fewer teams review the tools that help create that code.

That is the uncomfortable part of software supply chain security.

A developer extension can run on a machine.
A GitHub Action can run inside a workflow.
A Jenkins plugin can influence build behavior.
A container image can enter a deployment path.
A third-party developer tool can sit close to source code, credentials, environment variables, and build outputs.

That means the question is no longer only:

Is our code safe?

The better question is:

Which tools are allowed to touch the path from code to production?

That is the useful field note from the Checkmarx supply chain security incident update.

Checkmarx said the incident affected certain developer artifacts distributed through third-party channels, including VS Code extensions, GitHub Actions workflows, and a Jenkins plugin. The company also said it removed malicious artifacts, published clean replacements, rotated and revoked exposed credentials, and strengthened its GitHub and AWS environments after investigation with Mandiant.

This is not only a story about one company.

It is a reminder that developer tooling has become part of the product security surface.

Why developer tools deserve their own review

Developer tools are trusted by default because they help teams move faster.

That trust is practical.

Teams depend on extensions, actions, plugins, scanners, CLI tools, container images, package managers, CI runners, and automation scripts every day.

But convenience creates proximity.

A tool close to the development workflow may see or influence:

source code,
build scripts,
environment variables,
repository secrets,
CI tokens,
deployment paths,
package publishing,
artifact generation,
container images,
and local developer machines.

That does not mean every tool is unsafe.

It means tool trust should be reviewed, not assumed.

The hidden risk

A developer tool can create risk without looking like a normal application vulnerability.

It may not be part of your product codebase.

It may not be deployed to your production app.

It may not sit inside your cloud account.

But if it touches the build path, it can still matter.

For software teams, the important boundary is the delivery path:

Can this tool influence what reaches production, what credentials are used, or what artifacts are trusted?

If the answer is yes, it belongs in the security review.

The 7-check developer tool trust checklist

1. Tool inventory

Start by listing the tools that touch development and delivery.

That includes:

IDE extensions,
GitHub Actions,
Jenkins plugins,
CI/CD marketplace actions,
Docker images,
package managers,
scanners,
code assistants,
local CLIs,
deployment helpers,
and internal scripts.

The goal is not to create bureaucracy.

The goal is to know what the team already trusts.

Readiness question:
Which external tools can run inside our development or build workflow?

2. Install source

The same tool can come from different places.

A VS Code extension from one marketplace may not be identical to a similar package from another marketplace. A GitHub Action pinned to a branch is not the same as one pinned to a commit. A Docker image tagged latest is not the same as a pinned digest.

Review:

official marketplace source,
publisher identity,
download path,
package signature where available,
release history,
and whether the source is maintained.

Readiness question:
Do we know where this tool came from and whether the source is trusted?

3. Version pinning

Floating versions are convenient.

They are also harder to reason about.

If a workflow uses a moving tag, branch, or loosely pinned package version, the team may receive changes without an explicit review.

Use stronger version control for tools that touch sensitive paths:

pin GitHub Actions to commit SHA where needed,
pin container images to digest,
lock package versions,
review plugin updates,
and record why an update is accepted.

Readiness question:
Can this tool change under us without a review?

4. Permission scope

Developer tools should not receive broad access by default.

Review what each tool can access:

repository contents,
write permissions,
workflow tokens,
cloud credentials,
package publishing rights,
secrets,
local file access,
outbound network access,
and deployment permissions.

A tool that only needs to scan code should not be able to publish artifacts.

A workflow step that only needs read access should not carry write permissions.

Readiness question:
Does this tool have only the access needed for its job?

5. Artifact verification

Teams often focus on source code and forget the artifact.

But customers and production systems do not run intentions. They run built artifacts.

Review:

where artifacts are built,
who can publish them,
whether checksums or signatures are used,
whether build provenance is available,
whether releases are reproducible enough to trust,
and whether suspicious artifacts can be pulled back quickly.

Readiness question:
Can we prove the artifact came from the expected build path?

6. Network behavior

A compromised developer tool may try to communicate externally.

That does not mean every network call is suspicious, but it should be explainable.

For sensitive tools, review:

expected outbound domains,
telemetry behavior,
update endpoints,
package download endpoints,
webhook destinations,
and whether the tool can reach unknown infrastructure.

This matters in CI/CD and local developer environments.

Readiness question:
Do we know where this tool sends data?

7. Removal path

A tool review is incomplete without an offboarding plan.

If a tool becomes risky, the team should know how to remove it fast.

That means:

disabling the extension,
removing the workflow action,
replacing the plugin,
rotating any exposed credentials,
removing cached artifacts,
checking affected builds,
blocking known bad destinations,
and communicating the internal action clearly.

Readiness question:
If this tool were compromised, how quickly could we remove it and verify the path is clean?

A practical 30-minute review

Use this quick review for any tool that touches development or delivery.

Step 1: What is the tool?

Name the tool, source, owner, and current version.

Step 2: Where does it run?

Developer machine, CI runner, build server, cloud workflow, package registry, or deployment path.

Step 3: What can it access?

Code, secrets, tokens, artifacts, production credentials, cloud resources, package publishing, or customer data.

Step 4: What can it change?

Files, workflow output, build artifacts, releases, deployment steps, or published packages.

Step 5: How is it updated?

Manual review, automatic update, marketplace update, branch reference, tag reference, or pinned digest.

Step 6: How do we remove it?

Disable, revoke, rotate, replace, block network path, audit builds, and notify teams.

What founders should take from this

A founder does not need to approve every developer plugin.

But they should know whether the company has a policy for tools that touch the path to production.

The practical questions are simple:

Which tools can run in our build path?
Which tools can access secrets?
Which tools can publish or change artifacts?
Which tools are pinned and reviewed?
Which tools can be removed quickly if trust changes?

Software supply chain security is not only about open source libraries.

It is also about the trusted tools around the code.

The build path is part of the product.

If the build path is not reviewed, the product is carrying trust the business may not see.

Sources

OAuth app abuse: 7 checks before a connected app becomes a data access path

Shruti Saraswat — Thu, 16 Jul 2026 11:11:49 +0000

A SaaS breach does not always begin with a stolen password.

Sometimes the user approves an app.
Sometimes a vendor integration already has access.
Sometimes an OAuth token keeps working after the person who granted access is no longer part of the workflow.
Sometimes the activity looks normal because it is happening through an approved application path.

That is why Microsoft’s July 2026 analysis of ShinyHunters OAuth abuse matters.

Microsoft describes activity connected with ShinyHunters tradecraft targeting SaaS-based applications, including Salesforce environments, through OAuth abuse, vishing, supply-chain compromise, and misconfigured guest access. The key detail is important: Microsoft says the activity was not the result of an inherent Salesforce platform vulnerability. The attackers abused legitimate OAuth trust relationships for unauthorized access, data exfiltration, and persistence.

For software teams, the lesson is clear:

Authentication success is not the end of the security review. Connected app access needs its own control path.

Why OAuth app abuse is hard to notice

OAuth is designed to let users and organizations grant applications access to data or actions without sharing passwords directly.

That is useful.

It is also why abuse can be hard to spot.

If an approved app has access to Salesforce, Microsoft 365, Google Workspace, GitHub, Slack, or another business system, the activity may look like normal API use.

The attacker does not always need to break the main platform.

They may only need to get the wrong app approved, steal a vendor integration token, or abuse an existing trust relationship.

This is why ordinary sign-in monitoring can miss part of the story.

The user may not be logging in again.

The connected app may already have permission.

The 7-check OAuth app abuse playbook

1. List connected apps

Start with visibility.

Teams should know which apps are connected to core business systems.

That includes:

Salesforce apps
Microsoft 365 apps
Google Workspace apps
GitHub apps
Slack apps
CRM integrations
analytics tools
support tools
automation platforms
AI assistants
internal apps

The first question is simple:

Which apps can access company data right now?

If that list is unclear, the security review starts there.

2. Review OAuth scopes

A connected app should not have more access than the job requires.

Review OAuth scopes and permissions for each app.

Look for:

read access to sensitive records
write access where only read is needed
offline access or refresh tokens
broad admin permissions
access to exports
access to customer data
access to email, files, contacts, or CRM records
permissions that no longer match current usage

A scope that made sense during setup may become too broad later.

3. Identify high-risk integrations

Not every connected app carries the same risk.

Prioritize apps that can:

export customer data
access many accounts or workspaces
read CRM records
access support tickets
pull files or documents
read email or calendar data
manage identity or permissions
connect to production workflows

A low-use app with high access can be more dangerous than a popular app with narrow access.

4. Watch app behavior, not only user login

OAuth abuse can happen after the original user approval.

That means teams should monitor app behavior.

Watch for:

unusual API volume
exports outside normal patterns
access from unexpected locations
access outside business hours
sudden use of rarely used apps
changes in connected app behavior
access to unusual object types or records
vendor apps querying more data than expected

A user sign-in may look fine while the connected app is doing something risky.

5. Set app lifecycle rules

Connected apps should not live forever by default.

Define lifecycle rules:

Who can approve a new app?
Which apps need security review?
How often are apps reviewed?
When should unused apps be removed?
What happens when an employee leaves?
What happens when a vendor relationship ends?
How are refresh tokens revoked?

App access should expire when the business need ends.

6. Prepare revocation paths

When a connected app becomes risky, the team needs a fast response path.

That means knowing how to:

revoke the app
revoke refresh tokens
remove user consent
block future consent
rotate integration secrets
check affected records
notify the vendor
confirm whether data was exported

If the revocation path is unclear, the team may lose time during the incident.

7. Connect vendor risk with app access

A third-party vendor integration can become a path into customer data.

That does not mean teams should avoid integrations.

It means vendor risk and OAuth access should be reviewed together.

Ask:

What data does the vendor integration access?
Does it need that access continuously?
Can access be narrowed?
Does the vendor support audit logs?
What happens if the vendor is compromised?
Can the integration be disabled without breaking the product?
Who owns vendor-offboarding?

A trusted vendor should not mean unlimited app access.

A simple review workflow

Use this for a connected-app security review.

First pass: visibility

Export connected app list.
Group apps by business system.
Identify app owner.
Record OAuth scopes.
Flag apps with broad customer-data access.

Second pass: risk

Prioritize apps with export, write, admin, or offline access.
Check unused or low-use apps.
Review vendor-owned integrations.
Review apps approved by former employees.
Review guest and external-user access.

Third pass: controls

Remove unused apps.
Narrow scopes where possible.
Require review for new high-risk apps.
Set app review cadence.
Document revocation steps.
Add alerting for abnormal app behavior.

Founder takeaway

A founder does not need to inspect every OAuth scope personally.

But they should know whether the team can answer these questions:

Which third-party apps can access customer data?
Which connected apps have export or admin-level permissions?
Who approves new apps?
Who reviews old apps?
How fast can we revoke app access if a vendor or user is compromised?
Can we detect abnormal app behavior after the user has already granted consent?

The consequence of OAuth abuse is not only account compromise.

It is trusted access being used in a way the business did not intend.

That makes connected-app governance part of product security.

Sources

Passkey rollout decision: 6 checks before replacing password-first sign-in

Shruti Saraswat — Wed, 15 Jul 2026 06:47:02 +0000

Passkeys are no longer a distant authentication idea.

Users are seeing them in mobile apps, browsers, password managers, enterprise tools, and consumer platforms. Identity providers are improving the settings that make passkey behavior more predictable across devices and ecosystems.

That does not mean every SaaS product should remove passwords immediately.

The better decision is more practical:

Where should passkeys sit in the sign-in flow, and what fallback should remain when they do not work for a user?

That is the useful signal from Keycloak 26.7.0.

What changed

Keycloak 26.7.0 added better passkey compatibility through new WebAuthn policy options.

The important change is the new Discoverable credential setting.

Instead of the older yes-or-no style option, Keycloak now supports values that match the current WebAuthn specification:

required
preferred
discouraged

This matters because passkeys depend on the server telling the browser whether it wants a discoverable credential, which is often stored on the user’s device or password manager.

Keycloak says this improves compatibility with passkey providers such as iCloud Keychain, Google Password Manager, and 1Password.

The older Require Discoverable Credential option is now deprecated and planned for removal in a future release.

This is a technical change, but the product consequence is bigger:

Passkey rollout is becoming less about whether the technology exists and more about how carefully the product handles the transition.

Why this matters for SaaS teams

Authentication is not only a security layer.

It is part of the product experience.

If sign-in is too weak, the product carries security risk.

If sign-in is too difficult, users abandon the workflow, contact support, or create account recovery problems.

Passkeys can improve phishing resistance and reduce password friction. But they also introduce product questions that teams should answer before making them the default.

A user may be on a shared device.

A customer may use an enterprise password manager.

A team member may lose access to a device.

A browser may not support the same flow.

An admin may need to recover access for a user.

A legacy customer may still rely on password plus MFA.

So the decision is not simply:

Should we support passkeys?

The better question is:

How do we introduce passkeys without breaking access, trust, or support workflows?

The 6-check passkey rollout decision

1. User fit

Start with who uses the product.

A passkey rollout for a consumer mobile app is different from a rollout for an enterprise SaaS product, internal admin portal, developer tool, or healthcare platform.

Ask:

Are users mostly on personal devices?
Do they use managed corporate devices?
Do they switch devices often?
Do admins need centralized recovery?
Are users technical or nontechnical?
Are accounts shared by teams?

Passkeys work best when the product understands the user context.

2. Compatibility path

Passkey behavior depends on the browser, device, identity provider, password manager, and WebAuthn settings.

A product team should test common environments before rollout:

iOS and macOS
Android
Windows
Chrome
Safari
Edge
Google Password Manager
iCloud Keychain
1Password or enterprise password managers

The point is not to test every possible setup.

The point is to avoid treating one successful flow as proof that the rollout is ready for all users.

3. Fallback and recovery

This is the most important product question.

What happens when passkey sign-in fails?

A safe rollout should define:

backup authentication method,
account recovery flow,
admin-assisted recovery,
lost-device handling,
new-device setup,
support escalation,
and identity verification steps.

A passkey feature is incomplete without recovery.

Users do not only judge authentication when it works. They judge it when they are locked out.

4. Rollout sequence

Passkeys do not need to replace passwords in one step.

A staged rollout can reduce risk:

Offer passkeys as an optional sign-in method.
Encourage enrollment after successful login.
Make passkeys the preferred method for lower-risk accounts.
Require passkeys for admins or high-risk roles.
Phase down passwords only after recovery and support data are strong.

The rollout should match risk and user readiness.

5. Security policy

Passkeys can reduce phishing risk, but they still need policy decisions.

Teams should decide:

which roles require passkeys,
whether passkeys replace or complement MFA,
what happens for shared accounts,
how admin accounts are protected,
whether device-bound or synced passkeys are allowed,
and how suspicious sign-in attempts are handled.

The security policy should be clear enough for product, support, and customer success teams to explain.

6. Measurement

Teams should measure passkey rollout like a product change, not only a security setting.

Useful metrics include:

passkey enrollment rate,
successful passkey sign-ins,
failed sign-in attempts,
account recovery requests,
password reset volume,
support tickets,
user drop-off during sign-in,
admin adoption,
and risky login patterns.

If passkeys reduce security risk but increase lockouts, the rollout needs adjustment.

When to move now

A SaaS product should consider moving now when:

users already use modern devices and browsers,
account security matters,
phishing risk is meaningful,
support can handle recovery,
the identity provider supports proper WebAuthn settings,
and the product can roll out gradually.

This is especially relevant for admin portals, financial workflows, developer tools, internal systems, customer dashboards, and high-value accounts.

When to move more carefully

Teams should slow down when:

many users share accounts,
recovery is weak,
mobile and desktop flows differ too much,
support teams are not prepared,
enterprise customers require specific identity policies,
or legacy authentication is deeply tied into the product.

Moving carefully does not mean ignoring passkeys.

It means introducing them with the right fallback and support model.

A simple rollout plan

A practical rollout can start like this:

Phase 1: Optional enrollment

Let users add a passkey after a successful password login.

Use this phase to test compatibility and support load.

Phase 2: Preferred sign-in

Promote passkeys on the login screen and reduce password reliance for users who enroll.

Measure completion rate and recovery friction.

Phase 3: Required for sensitive roles

Require passkeys for admins, finance roles, security roles, or high-risk workflows.

Keep a strong recovery path.

Phase 4: Password reduction

Only reduce password-first sign-in after the team has enough data on adoption, recovery, support, and customer readiness.

Founder takeaway

Passkeys are becoming more practical.

But the product decision is not only “turn them on.”

The decision is:

who should use them first,
which devices and providers must work,
what fallback remains,
who owns recovery,
and what data proves the rollout is working.

A stronger sign-in method should not create a weaker access experience.

The right passkey rollout improves security and keeps users able to complete the product workflow.

Sources

When a security issue becomes a cloud bill: 6 checks for compute hijacking

Shruti Saraswat — Tue, 14 Jul 2026 10:26:37 +0000

A cloud security issue does not always start by taking a product offline.

Sometimes it starts by spending money.

A compromised workload can run unwanted compute. A stolen role can change cloud resources. A modified container can inherit permissions the original workload already had. A public-facing service can become the entry point into a wider cloud environment.

That is why AWS’s June 2026 Threat Technique Catalog update matters.

AWS added and updated techniques around Amazon EKS, organization-level trust, and compute hijacking. One of the clearest cost signals is compute hijacking in EKS, where attackers deploy cryptocurrency mining or other compute-heavy workloads inside compromised clusters, consuming customer resources and creating unexpected cost.

For SaaS and software teams, the important point is simple:

Security cost is not only incident response. It can also be unauthorized cloud usage.

What changed

AWS’s June 2026 Threat Technique Catalog update highlights several patterns that security teams should review.

The update includes EKS workload modification, public-facing application exploitation in EKS, assume root into organization member accounts, EKS compute hijacking, and unknown organization invitations.

These are different techniques, but they share one important pattern:

The attacker often works through functionality that looks normal from a distance.

A workload modification may change an existing pod instead of creating a new obvious resource. A role assumption may use cloud trust relationships that already exist. Compute hijacking may run inside a cluster where workloads are expected to run.

That makes context important.

The question is not only whether something happened.

It is whether the action fits the expected workload, identity, timing, and cost pattern.

Why compute hijacking deserves attention

Compute hijacking is easy to underestimate because it may first appear as a usage spike.

The product may still function. Customers may not notice immediately. The infrastructure may not look broken. But the cloud bill, cluster capacity, and security posture can all be affected.

In Kubernetes and EKS environments, the risk can become more serious when:

workloads have too many permissions,
namespaces lack resource quotas,
container images are not verified,
public-facing services are exposed too broadly,
runtime behavior is not monitored,
Kubernetes audit logs are not reviewed,
and service accounts can reach sensitive cloud resources.

A single compromised workload can create more than one problem.

It may consume compute, open paths to cloud credentials, affect cluster performance, and trigger investigation work across engineering, security, finance, and product teams.

The hidden cost is not only the extra compute

The extra compute charge is visible.

The full cost can be wider.

A compute hijacking event can create cost in several places:

cloud spend from unauthorized workloads,
engineering time to investigate,
product disruption if cluster resources are consumed,
emergency infrastructure changes,
delayed roadmap work,
security tool tuning,
access reviews,
customer communication if service quality is affected,
and future prevention work.

That is why the useful metric is not only the unexpected bill.

It is the total cost of finding, stopping, explaining, and preventing the issue.

The 6-check compute hijacking playbook

1. Check workload identity

Start with the identity attached to the workload.

In Kubernetes, service accounts and IAM roles can quietly define what a workload can reach. If a compromised pod inherits a broad service account, the attacker may gain access to more than the container itself.

Review:

which service account each workload uses,
what IAM role is attached,
whether permissions are broader than needed,
whether sensitive workloads share identities,
and whether role assumption patterns are monitored.

A workload should not carry permissions it does not need.

Readiness question:

If this workload were compromised, what could its identity access?

2. Watch workload changes

AWS highlighted EKS workload modification as a technique where attackers alter existing workloads by changing images, injecting sidecars, or modifying pod specifications.

That matters because nothing new may appear in an obvious way.

The workload already exists.

The change is what matters.

Teams should monitor:

pod spec changes,
image changes,
sidecar additions,
deployment modifications,
unexpected namespace activity,
unsigned or unapproved images,
and changes made by unusual principals.

If the team only watches for new resources, it may miss important modifications.

Readiness question:

Would we notice if a running workload changed in a way the product team did not approve?

3. Set resource boundaries

Compute hijacking becomes more expensive when workloads can consume too much capacity.

Resource quotas and limit ranges help reduce the blast radius.

They are not a complete security control, but they can stop one compromised workload from consuming more cluster resources than expected.

Review:

namespace quotas,
CPU and memory limits,
GPU limits where relevant,
autoscaling behavior,
node pool boundaries,
and alerts for unusual compute consumption.

The goal is not to slow the product team.

The goal is to make unexpected compute usage easier to detect and contain.

Readiness question:

Can one compromised workload consume far more capacity than it should?

4. Restrict image sources

Attackers may use legitimate-looking container images from public registries.

That means image scanning alone may not be enough.

Teams should decide which registries and image sources are allowed for production workloads.

Useful controls include:

approved registry lists,
signed images,
admission policies,
deployment review rules,
and alerts for unknown image sources.

If any public image can be pulled into a sensitive namespace, the cluster has a wider exposure surface.

Readiness question:

Can production workloads pull unapproved images?

5. Monitor cost as a security signal

Cloud cost monitoring is often treated as finance or FinOps work.

For compute hijacking, it becomes a security signal.

A sudden spike in compute usage, GPU use, node scaling, container restarts, or unusual workload duration can indicate more than ordinary traffic growth.

Security and cloud teams should share visibility into:

spend anomalies,
cluster utilization spikes,
new high-consumption workloads,
unexpected GPU usage,
unusual namespace-level cost,
and cost changes outside deployment windows.

A cloud bill can become an early warning signal.

Readiness question:

Would security teams see unusual compute spend quickly enough to act?

6. Define containment ownership

Finding unauthorized compute is not enough.

The response path should be clear before the issue happens.

A good runbook should answer:

who receives the alert,
who can isolate the workload,
who can revoke the role,
who can check cluster logs,
who can review cost impact,
who can restore the expected deployment,
and who updates prevention rules afterward.

This matters because compute hijacking crosses teams.

Security may find it. Platform may contain it. Product may see customer impact. Finance may notice the bill. Leadership may ask why usage changed.

The handoff should not be discovered during the incident.

Readiness question:

If unauthorized compute appeared today, who would stop it first?

A simple response workflow

When compute hijacking is suspected, use a clear order.

First 15 minutes

Identify the affected workload.
Check the service account and IAM role.
Stop or isolate the unauthorized workload.
Preserve enough logs for investigation.
Check whether the workload changed image, command, sidecar, or pod specification.
Review immediate cost and capacity impact.

First hour

Check Kubernetes audit logs.
Check AWS CloudTrail for related identity activity.
Review EKS, ECS, or container runtime alerts.
Look for related workloads in other namespaces.
Confirm whether credentials or tokens were accessed.
Notify the owning team.
Decide whether customer impact exists.

After containment

Tighten workload permissions.
Add or update resource quotas.
Review allowed image sources.
Strengthen admission controls.
Improve cost anomaly alerts.
Update the runbook.
Review whether similar workloads have the same weakness.

What founders should take from this

A founder does not need to manage every Kubernetes setting personally.

But they should understand the business pattern.

When cloud workloads are compromised, the impact may appear as cost, capacity loss, slower product paths, delayed delivery, or incident work before it becomes a full outage.

That is why cloud security and cloud economics should not be separated too cleanly.

A compute hijacking event asks both questions:

Who got access?

and

What did that access spend, change, or consume?

The strongest teams connect security monitoring, cost monitoring, workload ownership, and response ownership.

That is how an unexpected cloud bill becomes a fast investigation, not a long mystery.