For the CISO
Sovereign intelligence for the CISO
Give AI identity, permissions, policies and auditable controls.
The CISO has to secure something that reads untrusted text, holds credentials and takes actions. Traditional controls assume software does what it was coded to do, while an agent decides at runtime. This page sets out what worries security leaders and the questions that separate real controls from marketing.
What a CISO worries about
Agents acting with ambient authority
An agent that inherits a developer's credentials or a broad service account can do anything those credentials allow. Each agent needs its own identity with the narrowest scope that works.
Prompt injection and indirect injection
Instructions hidden in documents, emails or web pages can steer an agent. You cannot fully filter your way out; the defence is limiting what a hijacked agent can do.
Sensitive data in prompts and context
Personal data, credentials and confidential material flow into prompts, logs and caches. You need classification, masking and clear rules on what each model may see.
Evidence you cannot reconstruct
After an incident, the question is what the agent saw, which model answered, what tools it called and under which policy. Without the chain, you cannot investigate or prove anything. See traceability.
Vendor access to your tenant
Support staff, sub-processors and model providers may all touch your data. You need to know who, why, for how long, and what you can restrict.
What a Sovereign Intelligence Platform gives you
Identity for every actor
The fabric treats users, agents and workflows as known identities, with access scoped to each tool and data source. See governance.
Policy that changes what an agent can do
Allow, deny, warn, filter, escalate and require human approval are enforced at runtime. See governance versus guardrails.
A Trust Profile per AI system
The Trust Profile records allowed and restricted actions, data classification, residency, approval rules and policy set, so review has something concrete to check.
Auditable action traces
The platform is designed to record identity, data accessed, model used, tools called, policy applied, approval and outcome. Nexus is an entry point for capturing agent actions and enforcing policy in flight.
Deployment options that shrink the trust boundary
Private, dedicated and on-device options are designed to keep sensitive processing inside a boundary you choose. See the trust centre for what is true today and what is in progress.
Capabilities are described as what the platform is designed to let you do. For what is true today and what is not claimed, see the trust centre.
Questions to ask any vendor
Use this as a checklist in any evaluation, ours included. Each question comes with what a good answer looks like.
01What identity does each agent have, and how is its access scoped and revoked?
A good answer: A distinct identity per agent with least-privilege scopes, short-lived tokens and one-step revocation, visible in an inventory.
02Where are third-party credentials stored, and can the model ever see them?
A good answer: Credentials sit in a secrets store and are injected by the platform at call time. The model never receives raw secrets in its context.
03How do you defend against prompt injection, and what is the blast radius if it succeeds?
A good answer: Layered defences plus architectural limits: restricted tool scopes, approval for high-risk actions and separation of untrusted content from instructions. Claims of complete prevention are not credible.
04Is policy enforced before the action, and what happens if the policy engine fails?
A good answer: Enforcement is inline, evaluated on each call, and sensitive actions are denied if the engine is unavailable.
05What exactly is logged for each agent action, and who can alter the logs?
A good answer: Inputs, outputs, model, tools, policy decisions and approvals, with write access restricted. If tamper-evidence is not offered, the vendor says so rather than implying it.
06Can we export logs to our SIEM in near real time and keep them under our own retention rules?
A good answer: A streaming or API export in documented formats, with retention under our control, not only a vendor dashboard.
07How is our data separated from other customers, including caches and embeddings?
A good answer: Documented tenant isolation across storage, compute, caches and vector indexes, with dedicated options for sensitive workloads.
08Who at your company and your sub-processors can access our content, under what approvals?
A good answer: A named access policy with just-in-time approval, logging and customer notification. The sub-processor list is current.
09What encryption and key management options exist, and who holds the keys?
A good answer: Encryption in transit and at rest with a statement of the key hierarchy. Customer-managed keys are described as available or not available, not implied.
10Which security attestations do you hold, and which are still in progress?
A good answer: A frank list with dates. For anything in progress the vendor provides a questionnaire, architecture overview and test summary on request.
11Have you had an external penetration test, and can we see a summary?
A good answer: A summary shared under NDA, with remediation status. If no test has been done, the vendor says so and gives a date.
12What is your incident notification commitment and your runbook for an agent that misbehaves?
A good answer: A contractual notification window and a runbook with per-agent kill switch, forensic access to traces and a post-incident report.
Recommended reading
- Governance versus guardrails
- Runtime governance
- Guide: wire the trust fabric
- Why AI governance must run at runtime (blog)
- AI agent governance
Not sure where to start? Take the readiness assessment or read the build guide.
Frequently asked questions
Are guardrails enough to secure AI agents?
Guardrails answer whether something should be blocked. Governance also answers who is acting, under which policy, with which data and model, and whether you can prove it. You need both.
How should agent permissions be set initially?
Start read-only and narrow. Add write actions only where approval steps exist, and review the record before widening scope.
What should an AI audit trail contain?
At least identity, data accessed, model used, output, tools called, policy applied, decision, approval, action and outcome, as in the Trust Profile worked example.
Which security attestations does Swfte hold today?
Check the trust centre. It is the authoritative statement of what Swfte can show today, what is in progress and what is not claimed. Ask any vendor for the report or certificate itself under NDA. Swfte has no SOC 2 report or ISO 27001 certificate yet; a SOC 2 Type I audit is in preparation.
Build with control: for the CISO
Start with one entry point. Add intelligence, agents, workflows and infrastructure as you prove value. Or read the step-by-step build guide and take the readiness assessment.