SecOps / Security for AI
Agent runtime security: zero-trust for agents
Policy that changes what an agent can actually do, evaluated at the moment it tries to do it.
A review before deployment tells you what an agent was designed to do. Runtime security governs what it does now, with the data it just read, under the instruction it just received. For agents that act, the runtime is where security either exists or does not.
The problem: agents hold real authority and no one is checking
An agent is a non-human identity that decides for itself what to do next. It is handed credentials, tool access and sometimes a shell, and it acts at machine speed. Most organisations still apply human-era controls: a service account created once, broad scopes granted so nothing breaks, and logs that record that something happened but not why.
That leaves three gaps. First, identity: shared keys and inherited user tokens mean nobody can say which agent did what. Second, authority: permissions are set when the agent is built and never revisited, though its inputs change every minute. Third, enforcement: when a guardrail only advises, a manipulated or simply mistaken agent proceeds anyway.
Zero trust is the right starting point, with one change. Never trust, always verify, applied to an actor that may have been talked into something five seconds ago. Verification has to happen on every action, against a policy the agent cannot edit, before the action takes effect.
How the runtime layer works
Governance on Swfte is runtime, not paperwork. The same pattern applies whether the agent is a SOC agent, a coding agent or a business workflow.
Every agent has an identity and an owner
Agents and other non-human identities are inventoried with an accountable owner, a risk level and approved models. An agent with no owner does not run.
Permissions are explicit
Allowed tools, data sources, systems and actions are declared per agent, with restricted actions listed as clearly as permitted ones. Credentials are scoped to the task.
Policy is checked before the action
The verbs are Allow, Deny, Warn, Filter, Escalate and Require human approval. A call that violates policy is stopped before it executes and the reason is written to the audit ledger.
Isolation and blast radius
Agents that execute code or touch files run in bounded environments, and an identity graph shows what a compromised credential could reach, so containment is a decision you made in advance rather than during an incident.
Limits and kill switches
Rate limits, spend budgets and action caps stop a runaway loop. An operator can pause or revoke an agent immediately, and the revocation is itself recorded.
Autonomy changes are controlled
An agent cannot raise its own autonomy level. Changes are made by the accountable owner and recorded in the agent's Trust Profile.
Where it sits on the platform
One platform with several entry points. Each product below plays a defined part in this capability.
| Platform entry point | Role in this capability |
|---|---|
| Nexus | The runtime governance layer: capture, in-flight policy blocking, inventory of agents and non-human identities, identity graph and blast radius. |
| Studio | Where an agent's tools, scopes and approval rules are defined and versioned. |
| Connect | Brokered, scoped access to external systems rather than long-lived keys inside the agent. |
| Trust Fabric | Identity, access, policy, human oversight and auditability running through every layer. |
| Dedicated cloud | Run agents and models in an environment dedicated to your organisation, for isolation you control. |
What a code-executing agent can and cannot do
A Trust Profile for an engineering agent that runs commands, the case where runtime enforcement matters most.
Build Agent
Edits code, runs tests and opens pull requests in assigned repositories.
| Can | Cannot | Requires approval | Records |
|---|---|---|---|
|
|
|
|
Controlled autonomy for runtime actions
The level is a property of the action, the agent and the evidence, and it can be lowered at once if behaviour drifts.
- L1 Assist
Read-only access. The agent recommends commands; a person runs them.
- L2 Approve
The agent stages changes in a draft or sandbox. A person approves before they apply.
- L3 Supervise
The agent acts within explicit per-action limits and is monitored live, with alerts on policy hits.
- L4 Autonomous
Hard bounds enforced at runtime, automated anomaly detection and sampled human review.
- L5 Adaptive
Behaviour changes are gated and versioned. Boundaries cannot be modified by the agent.
The five-level model is described in full on the controlled autonomy page.
Frameworks the design is mapped to
Mappings of intent between controls and published risk lists. Not an assessment result.
| Framework | Entry | How the design addresses it |
|---|---|---|
| OWASP Top 10 for LLM Applications (2025) | LLM06 Excessive Agency | Minimised tools and permissions, per-action limits and approval for high-impact actions. |
| OWASP Top 10 for Agentic Applications (2026) | ASI02 Tool Misuse and Exploitation; ASI03 Identity and Privilege Abuse | Tool calls are policy-checked per action; each agent has its own scoped identity. |
| OWASP Top 10 for Agentic Applications (2026) | ASI08 Cascading Failures; ASI10 Rogue Agents | Budgets, rate limits, kill switches and inventory help contain loops and unregistered agents. |
| MITRE ATLAS | Agent-focused techniques added in recent releases | Capture and policy events are structured so a SOC can map agent behaviour to ATLAS techniques. Confirm current technique IDs at atlas.mitre.org. |
EU angle: oversight and cybersecurity by design
Swfte supports the evidence these instruments ask for. It does not make a system compliant by itself.
| Instrument | Reference | Supports evidence for |
|---|---|---|
| EU AI Act | Art. 14 human oversight; Art. 15 accuracy, robustness and cybersecurity | Art. 14 calls for effective ability to monitor, intervene and stop a high-risk system. Supports evidence of approval gates, kill switches and logs of overseer action. |
| NIS2 | Art. 21 risk-management measures | Supports evidence of access control, asset and identity management and policy enforcement. |
| DORA | ICT risk management and third-party risk | Supports an inventory of AI agents and dependencies, and a record of what each did, for financial entities in scope. |
| GDPR | Art. 32 security of processing | Supports evidence of access restriction and logging around personal data an agent can reach. |
Swfte is built compliance-by-design. It provides the technical controls, governance mechanisms and evidence required to deploy AI within an organisation's applicable regulatory, security and policy requirements. The exact posture depends on the customer's use case, jurisdiction, deployment and configuration. Nothing on this page is legal advice. Swfte's own security attestations are listed on the trust page.
What this page does not claim
- Nexus today is deepest for coding agents running under supported hooks, with transcript import for agents without native hooks. Wider runtime coverage is the direction of the platform.
- Isolation strength depends on the deployment you choose. No isolation guarantee is stated here.
- Policy only governs the actions it can see. Anything an agent does outside the governed path is a gap, which is why the inventory matters.
- Nothing here claims that your use of the platform is compliant with any regulation. Swfte's own security attestations are listed on the trust page.
Frequently asked questions
What is agent runtime security?
It is the set of controls applied while an agent is running: identity, scoped permissions, policy evaluated before each action, isolation, limits and a kill switch, plus a record of what happened. It complements design-time review and testing.
How is this different from LLM guardrails?
Guardrails answer whether a given input or output should be blocked. Runtime governance answers who is acting, allowed to do what, under which policy, with which data and model, at what risk and with what oversight, and whether you can prove it. Guardrails are one input to that decision.
Does policy block or only log?
It can block. Nexus evaluates policy before a tool call executes and denies protected files, forbidden commands and unapproved installs, with the reason in the audit ledger. Warn and escalate are available where a hard block is too blunt.
Can an agent change its own permissions?
No. Policy and autonomy level are set outside the agent's context by its accountable owner. Changes are recorded in the Trust Profile.
What is a Trust Profile?
A record on every AI system of identity, owner, risk level, approved models, data classification, residency, permitted systems, allowed and restricted actions, human approval rule, retention, audit and policy set.
The rest of SecOps
Nine pages cover both halves. Each has a different job.
AI for security operations
Frameworks and evidence
Back to the SecOps hub.
Build Agent runtime security with Swfte
Start with one agent and one policy, or talk to the team about your environment, your data and your regulators.