What Is Insecure Randomness?

What Is Insecure Randomness?

Insecure randomness is the use of predictable or low-entropy random number generation for security-sensitive values such as session IDs, password-reset tokens, API nonces, invite links, or agent tool secrets. It is an AI security weakness because LLM and agent workflows often ask tools to create one-time links, identifiers, sampling keys, or authorization tokens inside production traces. In FutureAGI, the issue is detected with InsecureRandomDetector before predictable randomness becomes account takeover, replay, or cross-session data exposure.

Why It Matters in Production LLM and Agent Systems

Predictable randomness turns helper code into a security boundary failure. A support agent may call a tool that creates a password-reset link; if that token comes from a timestamp-seeded PRNG, an attacker can enumerate nearby values. A RAG admin tool may mint a nonce for an upload callback; if the nonce repeats after a container restart, replay becomes possible. The named failure modes are account takeover, replay, CSRF bypass, cross-session leakage, duplicate job IDs, and audit evidence that cannot prove a value was unguessable.

The pain lands on several teams. Developers debug code that looked harmless because it passed local tests. SREs see symptoms such as repeated reset-token prefixes, collision spikes, duplicate nonces, identical “random” cohorts after deploy, or user sessions created with suspiciously close IDs. Security teams need to know whether the affected value was only an experiment bucket or an authentication boundary. Compliance teams ask whether any generated link exposed protected data.

Agentic systems make this easier to ship by accident. In 2026-era pipelines, tools create invite links, sandbox names, callback secrets, temporary file paths, and workflow IDs while the model plans the next action. Generated helper code often copies tutorial patterns such as Math.random() or Python random. The model is not the random generator, but the agent can trigger the vulnerable tool at scale.

How FutureAGI Handles Insecure Randomness

The FutureAGI anchor for this term is eval:InsecureRandomDetector, whose exact class name is InsecureRandomDetector. In a FutureAGI workflow, the detector is attached to code or agent-tool changes that can mint tokens, nonces, session IDs, reset links, invite links, or temporary secrets. The detector maps to CWE-330: use of insufficiently random values. A practical gate is simple: any InsecureRandomDetector finding in a route tagged auth-token, nonce, or session fails the release until the owner replaces the PRNG with a cryptographically secure source.

For example, a LangChain customer-support agent is instrumented with traceAI-langchain. A production trace shows the planner reaching agent.trajectory.step=issue_password_reset before calling a tool that returns a reset URL. The offline security eval runs InsecureRandomDetector against the tool source and flags the weak token generator. The engineer replaces Python random with secrets.token_urlsafe, rotates affected reset links, adds a regression eval for the tool, and keeps a zero-findings threshold for that route.

FutureAGI’s approach is to connect the detector result to the agent workflow that can exploit it. Unlike treating Semgrep-only SAST findings as a separate spreadsheet, FutureAGI lets the team line up the finding with traces, route tags, gateway pre-guardrail policy, and release thresholds. If a route later adds a new token-minting tool, the same detector runs before traffic reaches the new path.

How to Measure or Detect It

Measure insecure randomness as a security control with zero tolerance on sensitive paths:

• InsecureRandomDetector finding count - flags use of insecure random number generation associated with CWE-330; sensitive token, nonce, and session routes should stay at zero.
• Collision and replay signals - track duplicate token prefixes, repeated nonces, reset-link replay attempts, and same-seed behavior after deploy.
• Trace field agent.trajectory.step - identifies the planner or tool step that created the value, such as issue_password_reset or create_invite_link.
• Dashboard signal: eval-fail-rate-by-route - separate security-tool findings by route owner, model workflow, release, and repository path.
• User-feedback proxy - account recovery abuse, unexplained session swaps, or “I received someone else’s link” reports require trace review.

from fi.evals import InsecureRandomDetector

detector = InsecureRandomDetector()
result = detector.evaluate(input=tool_source_code)
print(result)

Pair detector findings with code review. The fix is usually to use language-native secure randomness, rotate exposed values, and add the vulnerable tool path to regression evals.

Common Mistakes

• Using simulation PRNGs for secrets. random, Math.random, and seeded NumPy target sampling or tests, not password-reset tokens or API nonces.
• Treating low collision rate as security. A value can be unique and still predictable enough for account takeover.
• Letting generated helper code mint tokens unchecked. LLM-written snippets often copy tutorial randomness patterns into production tools.
• Logging raw nonces during debugging. The randomness bug then becomes credential exposure and sensitive logging at the same time.
• Applying one scanner threshold everywhere. Token, session, nonce, key, and invite-link paths need zero tolerance; experiment buckets do not.