This page is shown in English while a reviewed translation for your locale is prepared.
Why We Treat Agentic Intent as a Governance Contract, Not a Mood
A plain-language Perspectis AI perspective: where agentic intent belongs in enterprise AI (policy, identity, tools, observability)—not only in prompts—and how we think about risk tiers and prompt injection.
A plain-language note for leaders, risk owners, and client teams (April 2026)
The short answer
“Agentic” systems are in the headlines: assistants that plan, call tools, and act with less hand-holding. We believe the ideas behind that shift are worth publishing as industry perspective—because the hard question is not whether models can sound confident; it is whether an organisation can defend who was allowed to do what, and why, when something goes wrong or when a regulator asks.
Perspectis AI is built so that intent (what work is being requested, and under whose authority) is carried in governance-friendly places—identity, policy, tool boundaries, and observability—not only in a model’s prompt. That is how we align “helpful assistant” energy with duty of care in professional environments.
What we mean by “intent” in plain language
In everyday language, intent is simply the goal of a request: “summarise this matter,” “draft an email,” “create an invoice,” “run a compliance check.”
In a serious platform, intent is also structural:
- Who initiated work (a person, a role, a service).
- Which capability is allowed to run (for example the Personal Agent Representative path versus a background job).
- What class of action is involved (reading records versus changing them versus money movement versus irreversible admin).
None of that should be implied only by clever wording in a chat box. We treat it as information the platform must understand and enforce—so the model is not the only place “intent” exists.
Why intent cannot live only inside the model
A large language model can interpret language; it cannot, by itself, be the system of record for permission, confidentiality, or billing policy.
We design around a simple principle: governance belongs in the application and data plane, not only in instructions to a model.
That means:
- Policy checks (features, roles, organisation boundaries) decide whether an action may proceed—even if the model “agrees” with a harmful or confused request.
- Tool and action registries decide which capabilities exist and how risky each one is; the model does not get to invent new privileged endpoints through persuasive text.
- Information barriers and similar controls still apply when an assistant retrieves or summarises sensitive material—because access rules are not negotiable in natural language.
This posture is how we reduce a whole class of failure modes where a fluent answer looks authorised but is not.
How we think about risk without drowning anyone in jargon
Different actions carry different real-world risk. We group that idea into a practical ladder many teams already recognise:
| Plain idea | What it tends to mean in operations |
|---|---|
| Read | Look things up; still needs correct access and confidentiality rules, but no lasting change by itself. |
| Act (change data) | Create or update records; deserves clear accountability and often a confirmation step in higher-risk channels. |
| Transact (money or billing) | Financial or invoice-adjacent work; deserves explicit confirmation and strong permissioning—because mistakes become commercial and reputational events. |
| Irreversible or destructive | Admin-style or hard-to-undo operations; deserves the tightest controls—and in our design direction, not the kind of work we want silently driven from the riskiest hands-free channels such as voice without extra safeguards. |
On top of per-action risk, we also care about human-in-the-loop patterns at the product level: where a human must approve, where a human monitors and can intervene, and where autonomy is intentionally bounded. That is not bureaucracy for its own sake; it is how regulated and reputation-sensitive organisations operate with evidence.
Prompt injection and “emergent” behaviour: what actually holds
Prompt injection (attempts to hijack or confuse an assistant with adversarial text) is a known industry concern. We take it seriously—and we are honest that no text filter is a magic wand.
What we emphasise to clients is the defence in depth story:
- Mitigation at the model boundary (detection, sanitisation, logging) reduces how much hostile text reaches the model unchanged.
- Hard gates in software still decide whether tools run, money moves, or restricted data is returned—so a manipulated model does not become a silent override for enterprise policy.
That combination is how we talk about safety without pretending the model is infallible.
Comparison at a glance (structural, not a weekly feature score)
We intend this table for stakeholder conversations—positioning, not a tick-box shootout. Products change quickly; architecture intent changes more slowly.
| Topic | Perspectis AI (how we build) | Typical consumer chat experiences | Organisation-built model and tool stacks |
|---|---|---|---|
| Where intent must live | Identity, policy, registries, structured requests, observability | Mostly in the conversation | Whatever each team implements |
| Who owns enforcement | The platform layer we ship and evolve | The vendor’s product + tenant admin choices | The adopting organisation’s engineering and security teams |
| Money-moving and irreversible work | Explicit risk framing, confirmations, channel constraints in our direction | Often out of scope or generic | Fully custom—powerful and responsibility-heavy |
| Model Context Protocol and tools | We treat tools as governed capabilities, not silent superpowers | Varies by product | Depends entirely on implementation quality |
| Audit story | Designed for “who approved what, and why” as a platform concern | Varies; often lighter | Fully custom |
| Best one-line mental model | Governed assistant inside an operating platform | Helpful conversational surface | Custom agent stack |
Why we publish this kind of perspective
Our customers are not only buying “an AI feature.” The real commitment is defensible operation: continuity, separation of duties, and a story that holds up when something misfires. We invest in public, plain-language framing—alongside deeper technical material for security and architecture peers—because our customers deserve clarity about what is marketing versus what is structural.
The Perspectis AI Demo Environment exists partly to make that difference tangible: not a single slick demo thread, but a broad catalogue of realistic scenarios where intent, policy, and workflow show up as first-class concerns.
Sources (external, for general industry context)
- OWASP: OWASP Top 10 for Large Language Model Applications
- NIST: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
This document is written for external, non-technical readers. Deeper technical assessments of controls, implementation status, and evidence live in our security and architecture documentation for customers and auditors.