Skip to main content

2 posts tagged with "Security"

View All Tags

Sandboxing LLM-generated code execution

· 13 min read
Xavier Blondel
Xavier Blondel
Engineering Manager Lead
Arthur Busser
Arthur Busser
Site Reliability Engineer
Romain Loisel
Romain Loisel
Security Engineer

Pigment provides a central AI platform to organizations for real-time business planning. Pigment AI is based on an agentic architecture that is described in more detail in this blog post.

One of our agents, the Analyst, already had multiple tools to perform simple calculations, such as contribution and variance analysis. In order to add more capabilities, we decided to leverage the code generation feature of LLMs rather than creating a dedicated tool for each capability.

LLM-generated code cannot be trusted by default. It is produced from user-controlled input, which means users may intentionally or accidentally steer the model toward unsafe behavior: reading sensitive data, calling internal services, exfiltrating data, pivoting into internal infrastructure, or exhausting compute resources. From a security perspective, the generated code has to be handled as an untrusted workload.

That requirement led us to build a sandboxed execution environment. In this article, we explain how we went from the initial risk analysis to a proof of concept, and eventually to a production-ready sandbox with support for large datasets.

Impersonation Done Right: Tokens, Read-Only Guarantees, and Audit Trail

· 13 min read
Aymeric Bouzy
Aymeric Bouzy
Software Engineer

If you build enterprise SaaS with any kind of permissions model, you've heard this feature request before: "Our admins need to see what a user sees." The motivation is always the same — a user reports they can't access something, or they're seeing the wrong data, and the admin has no good way to verify what's going on from the user's perspective.

The workarounds your customers resort to are painful. They ask their users for screenshots, or schedule screen shares, but these are high-friction interactions. They try to reproduce the issue with test accounts, but test accounts never have the same permissions, the same data, or the same organizational context as the real user.

So sooner or later, the feature request lands on your backlog: let admins log into the app as another user — see the same dashboards, the same data, the same permissions. Even before users complain about missing access.

But the moment you say "admin impersonation" in an enterprise context, alarm bells go off. Can the admin modify the user's data? Can they access private information? Is there an audit trail? How do you prevent this from becoming a backdoor?

These are fair concerns. At Pigment, we built a user-facing impersonation mode that lets admins review what users see safely. It's been in production for a while now, and our customers love it. Here's how we designed it.