How AI Agents Decide What They're Allowed to Touch
Every AI vendor says their agents are safe. The specific mechanism underneath that claim — risk tiers, a taint model that clamps a run to read-only, and hard-coded approval gates on the actions that matter most — is what actually answers the question.
"Our AI agents are safe" is the least differentiated sentence in enterprise software right now. Every vendor selling agentic AI says some version of it, and almost none of them say what it actually means mechanically. That gap is the reason agent adoption is stalling in exactly the places where the stakes are highest: recent enterprise research on agentic AI puts human-in-the-loop rates above 60% in legal and compliance workflows specifically, and cites a lack of governance maturity — real-time monitoring, audit trails, the ability to actually stop a run — as the thing separating agent deployments that survive from the roughly 40% at risk of being cancelled by 2027. The organizations asking the sharpest questions about agent safety aren't being paranoid. They're asking the question that determines whether the deployment sticks.
So here's the actual mechanism behind that claim for Piskes, not the marketing version of it.
Every capability carries a risk tier
Agents don't get an undifferentiated pool of "things they can do." Every action an agent can take — checking a CRM record, drafting a message, updating a task, deleting a record, sending a campaign — is registered as a capability with an explicit risk classification: low-write or high-write. That classification isn't a suggestion the agent can reason its way around; it's metadata the platform checks before a capability is allowed to execute at all.
Layered on top of risk tier is an approval requirement, also set per capability: some actions can run with no human involved, some require the requesting user to approve before they execute, and some require an admin specifically — not just any authorized user — to sign off. The distinction matters because it means "requires approval" isn't a single blanket switch a platform can quietly loosen. A capability that's admin-gated stays admin-gated regardless of who's driving the agent session.
Some actions are structurally off-limits to AI, not just discouraged
The strongest part of this model isn't the risk tiers — it's what sits below them. A specific set of capabilities is hard-set as not exposable to AI at all, at the capability-registry level, not as a runtime check an agent could theoretically be prompted around. Every CRM delete action, every email campaign send, and every identity-management capability falls into this category. An agent cannot be talked into deleting a CRM record or sending a mass email campaign, because those capabilities simply aren't in the set an AI-driven session is allowed to invoke — the same way a read-only database user can't be prompted into running a write query. The restriction lives below the level where a clever prompt could reach it.
Taint: what happens when external content enters a run
The mechanism worth understanding in most depth is how the platform handles content provenance during a run. Every piece of content an agent touches carries a taint classification — platform, tenant, or external — tracking where that content actually came from. Platform content is Piskes's own; tenant content is your organization's; external content is anything that entered the run from outside both, most commonly the output of a web fetch, an email from an unknown sender, or a document from an untrusted source.
The moment external content enters a run, the entire run clamps to read-only — automatically, not as a judgment call the agent makes in the moment. This is the concrete answer to prompt injection: it's not solved by having the model try harder to recognize a manipulative instruction hidden in a fetched web page. It's solved by making the entire category of "external content plus a high-write action in the same run" structurally impossible, regardless of what that content says or how persuasively it says it. An agent that's read something from outside the trust boundary simply cannot take a write action in that same run, whether or not the content it read was actively trying to manipulate it.
Why this is the honest answer to "how do you keep this safe"
None of this promises agents that never make mistakes — that's not a claim anyone can honestly make about a system built on a language model. What it does provide is a specific, checkable set of properties: an agent cannot invoke a capability outside its declared risk tier, cannot execute a high-write action without the approval level that capability actually requires, cannot touch the handful of capabilities carved out as never AI-exposed regardless of instruction, and cannot combine reading untrusted external content with taking a write action in the same run.
Those are architectural constraints enforced by the capability registry and the taint model, not behavioral guidelines the model is asked to follow. That distinction — a rule enforced by the system versus a rule the model is instructed to respect — is exactly the distinction a security-conscious evaluator should be pushing every AI vendor to draw clearly, and it's the one most "our agents are safe" marketing quietly avoids making.