Topic starter
06/11/2026 6:36 pm
TL;DR: The trust problem is no longer whether AI can act, but whether governance, permissions, and audit trails can constrain what those agents touch, according to Serval research. Serval says its acquisition of software supply chain startup Ensignia will put founder Sam Stewart in charge of security as the company expands AI agents deeper into sensitive enterprise workflows, including detection and response, application security, and infrastructure security.
Editorial analysis by NHI Mgmt Group, based on content published by Serval: “Sam Stewart joins Serval as Head of Security”.
By the numbers:
- Serval raised a $75 million Series B led by Sequoia Capital in December 2025.
Key questions
Q: How should security teams govern AI agents that can access enterprise systems?
A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring.
Q: Why do audit trails matter for agentic workflows?
A: Audit trails matter because agentic workflows need a defensible record of what the agent saw, decided, and changed, especially when it acts with delegated authority.
Q: What is the difference between AI governance and AI runtime security?
A: AI governance focuses on policies, documentation, approvals, fairness checks, and regulatory evidence.
Practitioner guidance
- Define runtime trust boundaries for AI agents Map every system an agent can touch, then classify which actions require task-scoped approval, which can run autonomously, and which must remain blocked.
- Separate build trust from operational trust Use software supply chain controls for code integrity, but add distinct governance for the identities, tokens, and API paths an agent uses at runtime.
- Instrument agent actions for auditability Capture tool calls, approval state, system targets, and execution outcomes so security teams can reconstruct agent behaviour during incident review.
Bottom line: AI agents that can operate in sensitive enterprise systems need runtime governance, not just deployment-time permissioning.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/11/2026 6:41 pm
Agentic security governance now depends on runtime authority, not just deployment trust: once AI agents can operate inside customer systems, the decisive question is what they are allowed to do at the moment of action. Static permissions and broad automation approvals do not answer that question cleanly, because the risk emerges in-session. Practitioners should treat this as a governance problem about action scope, not just a product safety feature.
A few things that frame the scale:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
A question worth separating out:
Q: When should security teams restrict agent access to customer systems?
A: Security teams should restrict agent access to customer systems before the agent can make external changes, handle personal data, or trigger irreversible actions without human review. Limit the agent to the narrowest API scopes, require step-up approval for a customer-facing or high-impact workflow, and bind access to a named human owner who can suspend the agent quickly.
👉 Read our full editorial: Serval acquisition signals tighter security for enterprise AI automation