Connect with us

Tech

How AI Agents Actually Get Compromised: A Walkthrough

Published

on

Horizontal bar chart showing an illustrative view of which stage of the AI agent lifecycle most compromises are typically caught at.

An AI agent compromise rarely looks like a single dramatic breach. It usually looks like a small permission that should not have been granted, a prompt that should not have been trusted, or a behavior change nobody was watching for. Understanding where these failures actually originate is more useful than treating agent security as one generic risk category.

Where does the exposure usually start?

Most agent compromises trace back to over-broad permissions granted at setup, not to some sophisticated exploit. An agent built to answer questions about public product information gets connected to a shared drive that also contains HR records, because it was faster than scoping access precisely.

This is the same review gap that agentic AI security work is meant to close: catching over-broad access at configuration time, before the agent is ever exposed to untrusted input.

How does prompt injection actually change an agent’s behavior?

Prompt injection works by embedding instructions inside content the agent is supposed to process, such as an email, a document, or a webpage, so the agent treats attacker input as a legitimate instruction from its operator. The agent has no inherent way to distinguish trusted instructions from instructions smuggled inside the data it was asked to read.

This is why input validation for agents needs to go well beyond what worked for traditional applications. A field-length check does nothing against an instruction hidden inside a PDF the agent was asked to summarize.

The practical difficulty is that the agent’s core function, reading and acting on unstructured content, is the same mechanism an attacker exploits. Restricting what the agent can read would defeat its purpose, which is why the more workable answer sits at the permission and monitoring layer rather than at the content layer alone.

Why does static, pre-deployment review miss so much?

A one-time security review captures the agent’s configuration at a single point in time. It says nothing about how the agent behaves three months later, after its underlying model has been updated, after a well-meaning employee has expanded its permissions, or after it has been connected to a new data source.

Platforms built for real time adaptive agent protection are designed specifically to close this gap, establishing a behavioral baseline for each agent and flagging deviations as they happen rather than relying solely on the original review.

What does runtime monitoring actually catch that testing does not?

Pre-deployment testing can catch misconfigurations and known vulnerability patterns, but it cannot observe how an agent behaves against real, unpredictable input over time. Runtime monitoring is where behavior changes, unusual data access patterns, and signs of prompt injection typically surface first.

This is also where AI agent runtime protection becomes distinct from traditional application security tooling. It has to account for agents whose actions are generated dynamically rather than executing a fixed, pre-written code path.

Does the platform the agent runs on matter?

Agents built inside low-code and automation platforms inherit the security posture of that platform, for better or worse. A platform with weak default permission scoping makes it easier for an agent to end up over-privileged even when the person building it had no harmful intent.

Reviewing Microsoft Power Platform security risks specifically, rather than assuming general cloud security practices cover agent-building platforms adequately, tends to surface gaps that a generic review would miss.

Horizontal bar chart showing an illustrative view of which stage of the AI agent lifecycle most compromises are typically caught at.

Illustrative view of where AI agent compromises tend to surface across the lifecycle. General pattern, not a measured detection-rate study.

Where This Leaves Security Teams

None of these stages operates in isolation. Over-broad permissions make prompt injection more dangerous once it succeeds, and the absence of runtime monitoring means a compromised agent can operate unnoticed for a long stretch after the initial failure. Evaluating agent security across the full lifecycle, from initial permission scoping through ongoing runtime behavior, tends to predict real-world resilience far better than evaluating any single stage on its own.

Frequently Asked Questions

What is prompt injection in AI agents?

Prompt injection is a technique where instructions are embedded inside content an AI agent processes, such as a document or webpage, causing the agent to follow attacker-supplied instructions as if they came from its legitimate operator.

Can pre-deployment testing alone secure an AI agent?

Not on its own. Pre-deployment testing captures a snapshot of the agent’s configuration and known vulnerability patterns, but it cannot observe how the agent behaves over time as models update, permissions change, or new data sources get connected.

Why do AI agents need runtime monitoring specifically?

AI agents can change behavior after deployment in ways traditional static software does not, so runtime monitoring is often where unusual data access, permission creep, and signs of prompt injection are first detected.

Continue Reading

Tech

7 Signs Your AI Guardrails Won’t Survive Contact With Agentic Systems

Published

on

Bar chart comparing the latency of a general purpose language model used as a safety classifier against a purpose built guardrail model

Two years ago, a guardrail conversation was mostly about content filtering: stop the chatbot from saying something toxic. The model produced text, the text was safe or it was not, and a classifier could usually tell. In 2026 the problem changed shape, because the model is no longer just producing text. It is calling APIs, querying databases, writing files, sending emails, and triggering workflows. A guardrail failure two years ago meant a bad response. A guardrail failure today can mean a bad action: data deleted, funds transferred, privileged information forwarded to the wrong recipient. Here are seven signs an enterprise’s guardrail approach has not caught up to that shift.

  1. Guardrails only inspect the chat interface

If the only place content is being checked is the conversational turn between user and model, agentic workflows are moving around that checkpoint entirely. Tool calls, intermediate outputs passed between chained steps, and data pulled from connected systems all need coverage, not just the visible chat window.

  1. There is no human checkpoint on irreversible actions

Database deletions, external data transfers, financial transactions, and bulk record modifications are operations where a mistaken or manipulated instruction can cause damage that is difficult or impossible to reverse. Enterprises that have not annotated their AI tools by risk level, and built approval flows for anything tagged destructive, are relying entirely on the model getting it right every time.

  1. The guardrail is a prompted general purpose model

Prompting a general purpose model to act as its own safety classifier is the fastest way to prototype a guardrail, and it is also the slowest one to run in production. The chart below shows why that tradeoff matters once guardrails sit inside an agent’s decision loop rather than at the end of a conversation.

Bar chart comparing the latency of a general purpose language model used as a safety classifier against a purpose built guardrail model

Illustrative figures based on reported benchmark ranges for general purpose models prompted as classifiers versus purpose built guardrail models, 2026.

  1. Policies are generic instead of specific to the workflow

Out of the box guardrails ship with a fixed taxonomy covering hate speech, violence, sexual content, and basic PII. That is fine for a generic chatbot. It is not fine for a workflow that needs to enforce specific regulatory language, recognize an organization’s own confidential project names, or apply industry-specific rules no generic model has ever seen. Generic guardrails catch generic problems and miss the ones that actually matter to a given business.

  1. There is no governance layer over employee AI usage

Guardrails on a single deployed application do nothing for the AI tools employees adopt on their own. Consistent governance over employee AI tool usage across sanctioned and unsanctioned tools alike is what turns a guardrail policy from something that applies to one system into something that actually reflects how AI is used across the organization.

  1. Nobody has adversarially tested the guardrail itself

A guardrail that has only been validated against the cases it was designed to catch will fail the first time it meets an adversarial input it was not trained on. Open source community-standard guard models, for example, see measurable accuracy drops under adversarial pressure and on long context traces compared to their baseline performance. Red teaming the guardrail, not just the underlying model, is what closes that gap before an attacker finds it.

  1. Governance is only 25 percent implemented, if that

According to a 2025 industry survey, only about 25 percent of companies report a fully implemented AI governance program, even as 88 percent of organizations say they use AI in at least one business function. That gap between usage and governance is exactly where the enterprise AI security risks CISOs are already tracking tend to surface first, since guardrails without an underlying governance program are enforcing rules nobody has actually agreed on organization-wide.

What closing these gaps actually requires

The pattern across all seven signs is the same: guardrails designed for a single conversational turn do not generalize to a system that acts. Closing the gap means covering tool calls and not just chat, gating irreversible actions behind human review, using purpose-built models fast enough to run inline, tailoring policy to the specific workflow, extending governance to tools employees adopted informally, adversarially testing the guardrail itself, and treating all of it as a program rather than a one-time deployment. A recent look at how enterprises are approaching the related discipline of preventing AI data leakage is worth reading alongside guardrail planning, since the two controls typically need to work together

Frequently Asked Questions

Are guardrails the same thing as AI governance?

No. Guardrails are the runtime controls that catch or block specific behaviors. Governance is the broader program, ownership, policy, and accountability structure that decides what those controls should actually enforce.

Why do agentic systems need different guardrails than chatbots?

Chatbots produce text a human reads before acting on it. Agents can take the action directly, so a guardrail failure has a much larger and sometimes irreversible blast radius, which changes both what needs to be checked and how fast the check needs to run.

What is the fastest way to test whether current guardrails are sufficient?

Red team them the same way the underlying model would be tested, using adversarial examples specific to the organization’s actual policies and workflows rather than relying only on the vendor’s published benchmark results.

Continue Reading

Electronics

GPS Over Fiber: How Buildings Get Precise Timing Signals Indoors

Published

on

Line chart comparing coax cable attenuation to fiber optic loss across frequency.

Buildings, tunnels, and parking structures block GPS satellite signals from reaching the devices that depend on them for precise timing. Distributing a single rooftop GPS signal to many indoor locations without losing accuracy is a common, and often underestimated, engineering problem. This piece walks through how GPS over fiber distribution solves it, in plain question-and-answer form.

Why can’t you just run coax to every timing device?

Coaxial cable loses signal strength as it gets longer, and that loss gets worse at higher frequencies. GPS signals sit up near 1.5 GHz, a range where coax attenuation climbs quickly. Once a cable run stretches beyond roughly a hundred feet, the accumulated loss can degrade the signal below what a receiver needs to lock onto it reliably.

Line chart comparing coax cable attenuation to fiber optic loss across frequency.

Nominal coax attenuation rises steeply with frequency, while fiber optic loss stays comparatively flat and low (illustrative, not a specific product measurement).

How does the fiber-based alternative work?

A rooftop GPS antenna feeds a transmitter module that converts the incoming satellite signal onto an optical carrier. That optical signal travels over low-loss fiber, and can be split to reach many destinations at once using standard optical splitters, before a fiber optic transmitter and receiver pair converts each branch back to an RF GPS signal at its endpoint. Because a single donor antenna can feed dozens of splits, one rooftop receiver can serve timing devices scattered across an entire facility.

What actually needs this kind of precise timing?

Data centers rely on GPS timing to keep distributed systems synchronized. Financial networks use it to timestamp transactions consistently across locations. Highway tunnels sometimes need GPS re-radiated inside for emergency vehicle navigation. In each case the requirement is the same: get an accurate, undistorted GPS signal to a location the satellite signal itself can’t reach directly.

How precise does GPS timing actually get?

According to the U.S. government’s official GPS information site, GPS time transfer is commonly used to synchronize clocks and networks to Coordinated Universal Time, with a typical accuracy relative to the U.S. Naval Observatory’s time standard of 30 nanoseconds or better, 95 percent of the time, when using a dedicated time-transfer receiver. See GPS.gov’s overview of GPS timing applications for more detail on how that precision is used across industries.

Frequently Asked Questions

Why does GPS signal distribution need fiber instead of just more coax?

Coax loss increases sharply at GPS frequencies, so runs longer than about a hundred feet start to degrade signal quality. Fiber optic loss stays low over much longer distances.

Can one GPS antenna really serve an entire building?

Yes. Once the signal is converted to an optical carrier, it can be split many times using standard optical splitters, letting a single rooftop antenna feed numerous indoor endpoints.

What industries rely most on distributed GPS timing?

Data centers, financial networks, and telecommunications infrastructure are common users, since all depend on precise, synchronized time across multiple locations.

Continue Reading

Tech

How a Venture Capital Fund Actually Works, From First Close to Exit

Published

on

Timeline diagram showing the four stages of a venture capital fund lifecycle, from fundraising to exits.

When people talk about “venture capital,” they often collapse two different things into one term: the venture capital firm and the venture capital fund it manages. A firm can run several funds at once, at different stages, sectors, or vintages, but each individual fund has its own life cycle, its own investors, and its own clock ticking toward a defined end date. Understanding that structure explains a lot about why VCs behave the way they do, particularly around timelines, follow-on decisions, and exit pressure.

Who actually puts up the money?

Every venture capital fund is built around two groups of participants. Limited partners, typically pension funds, university endowments, insurance companies, family offices, and high-net-worth individuals, supply the bulk of the capital but take no role in day-to-day investment decisions. General partners raise the fund, decide where capital goes, sit on portfolio company boards, and are compensated through a management fee (commonly around 2% of committed capital annually) plus carried interest (commonly around 20% of profits once the fund clears a minimum return threshold, known as the hurdle rate).

Why do funds have a fixed lifespan?

Most venture capital funds are structured as closed-end vehicles with a defined term, typically ten years, sometimes extended a year or two at the general partner’s discretion. That structure is not incidental. LPs commit capital for a fixed period specifically because venture investing requires patience: it can take five to ten years for a startup to reach a meaningful exit, and a fund with no fixed term would have no built-in mechanism for actually returning capital to its investors.

Timeline diagram showing the four stages of a venture capital fund lifecycle, from fundraising to exits.

The typical life cycle of a closed-end venture capital fund, from initial deployment through final distributions.

What happens during that ten-year window?

  • Years 0–2, Fundraising and deployment: the GP closes commitments from LPs and begins actively sourcing and investing in portfolio companies.
  • Years 3–6, Active portfolio management: most new investments happen in this stretch, alongside board support, follow-on decisions, and company-building work.
  • Years 6–8, Follow-on and maturation: new investments slow considerably as capital increasingly goes toward defending ownership stakes in the fund’s strongest performers.
  • Years 8–10+, Exits and distributions: portfolio companies reach acquisition, IPO, or other liquidity events, and the fund returns capital, plus any profit, back to its LPs.

Why does a small number of investments matter so much?

Venture returns tend to follow a power-law distribution: a small percentage of investments in a given fund typically generate the majority of that fund’s total returns. That dynamic explains why funds concentrate follow-on capital on their strongest performers rather than spreading it evenly, and why a fund’s venture capital investor relations function, keeping LPs informed on portfolio performance, valuations, and expected timelines, becomes increasingly important as a fund matures and LPs look for visibility into when they can expect distributions. Firms that maintain clear, consistent investor relations practices tend to have an easier time raising their next fund from the same LP base.

What does this mean if you are raising from a VC fund?

  • Ask where the fund is in its lifecycle. A fund in years one to three has more capital and time to support you through several rounds; a fund in years eight-plus is focused on exits and may have little dry powder left for new bets.
  • Understand that a GP’s fund economics (fees, carry, hurdle rate) shape their incentives, not just their stated investment thesis.
  • Recognize that “closed-end” does not mean inflexible: many funds retain reserves specifically for follow-on investment in their winners.

Frequently Asked Questions

How long does a typical venture capital fund last?

Most are structured with a roughly ten-year term, sometimes extended by a year or two, split between an active investment period and a longer tail focused on portfolio management, follow-ons, and exits.

What is the difference between a venture capital firm and a venture capital fund?

A firm is the overarching organization; a fund is one specific pool of capital, with its own investors and its own lifecycle, that the firm manages. A single firm can manage several funds at once.

How do venture capital funds actually make money for their investors?

Primarily through management fees (typically around 2% of committed capital annually) and carried interest (typically around 20% of profits above a minimum return threshold), paid once portfolio companies exit through an acquisition, IPO, or other liquidity event.

Continue Reading

Trending