Frequently Asked Questions

Coding agent sprawl is what happens when an engineering organization adopts multiple AI coding tools — Cursor, Claude Code, Codex, and others — without a centralized layer to govern them. Each tool carries its own identity, its own data access permissions, and its own cost footprint, with no coordination between any of them. A developer connecting a coding agent to internal Jira tickets, GitHub repositories, and Confluence docs through an MCP server can accidentally create an agent with more data access than any human developer on the team — and no audit trail to show what it read or acted on. The risks are real: runaway inference costs, ungoverned data access, compliance exposure, and zero visibility for security or finance teams. Organizations need centralized identity, cost controls, and audit logging that cover every coding tool simultaneously, not tool-by-tool.

AI monitoring is the continuous observation of how an AI system behaves in production — tracking output quality, model drift, cost, latency, error rates, and user behavior patterns over time. AI governance defines who is accountable for the system, what policies apply to it, and how decisions about it get made. Monitoring generates the signals; governance uses those signals to make decisions and enforce accountability. A well-governed AI system has monitoring in place so that governance teams can see when something drifts, degrades, or violates policy. Without monitoring, governance operates on assumptions about what the system is doing rather than evidence.

AI governance defines the rules, accountability structures, and policies that determine how AI systems should operate. AI security enforces those rules at the moment of execution — blocking harmful actions, filtering dangerous inputs, and preventing data from leaving systems it shouldn't leave. Governance is the policy layer; security is the enforcement layer. A governance framework that says "agents cannot access customer PII without authorization" is useless without a security control that actually stops the agent from accessing that data in the first place. Most organizations need both, and they need them connected. Governance without security is a wish list. Security without governance is enforcement without a clear standard to enforce against.

Shadow AI refers to AI tools and models that employees use without IT or security approval. A team member signs up for an AI writing tool, pastes internal strategy documents into it, and sends the content to a third-party model's training pipeline — all without anyone in security knowing it happened. Shadow AI is widespread because the tools are easy to access and genuinely useful. Detection requires active scanning of browser traffic, endpoint activity, and cloud tenant connections for unauthorized LLM usage, plus a live registry of every sanctioned AI tool in the environment. Organizations that can't answer the question "what AI tools are running in our environment right now" have a shadow AI problem by definition.

Prompt injection is an attack where malicious instructions are hidden inside a user input or connected data source, tricking an AI model into overriding its original instructions. A support ticket with an embedded command, a document with encoded payloads, a database field with rogue instructions — all of them can redirect a model's behavior without triggering any conventional security alert. The risk is serious because AI models are trained to be helpful, which means they follow instructions. A model that reads a poisoned input and complies is doing exactly what it was designed to do. Organizations need input validation and prompt filtering controls sitting directly in the request path — before the model reads anything — to defend against this class of attack.

Continuous evaluations are automated checks that score every production interaction an AI agent handles — not just a sample, not just the ones that generate complaints. For buyers evaluating platforms, the key questions are: does the platform run evaluations at inference time or as a batch job after the fact, how granular is the scoring, and can you configure what "correct" looks like for your specific use cases. Platforms that only offer manual review workflows or periodic batch scoring leave gaps where agent behavior can drift for days before anyone notices. Continuous evaluation capability is what separates a governance-ready platform from one that gives you visibility only after the damage is already done.

Observability for AI agents means a platform captures the full internal trace of every decision — every model call, every tool invoked, every piece of context retrieved, every reasoning step taken — so you can see exactly what happened during a session, not just what came out at the end. For buyers, strong observability means being able to replay any failure, attribute behavior changes to a specific prompt version or model update, and produce that trace as auditable evidence for compliance reviews. Without it, you're governing from final outputs only — which means you can see that something went wrong but have no way to trace where in the decision chain it broke. That's not a governance posture; it's forensics after the fact.

Testing checks how an agent behaves in a controlled environment with known inputs. Monitoring shows how it behaves with real users and unpredictable data over time. Both are necessary because an agent can pass every pre-deployment test and still drift significantly once it hits production — real user behavior, shifting data patterns, and upstream system changes all introduce variables that testing can't fully anticipate. From a governance standpoint, monitoring is what keeps policy enforcement connected to reality after deployment. A governance framework without production monitoring is a set of rules that only apply to the demo. For a full breakdown of the signal categories that matter most in production AI monitoring, see the GAIG monitoring signals guide.

Your compliance obligations change with it. The EU AI Act classifies AI systems by risk level and attaches different requirements to each category. If a system begins as a minimal or limited risk tool and later gets used in a context that places it into the high-risk category — such as hiring decisions, credit assessments, or healthcare applications — the full set of high-risk obligations applies from that point forward. That includes conformity assessments, detailed technical documentation, mandatory human oversight mechanisms, and ongoing post-market monitoring. The underlying technology does not need to change for the classification to shift. How the system is used determines the category, which means compliance needs to be reassessed whenever the use case evolves.

Yes. GDPR applies to any organization anywhere in the world that processes personal data belonging to individuals in the European Union. If you have European customers, users, or website visitors whose data you collect in any form, GDPR obligations apply to you regardless of where your company is incorporated or headquartered. Fines for non-compliance can reach up to four percent of global annual revenue and are enforced by EU data protection authorities who have acted against US companies before. Being based in the US does not create an exemption.