Sigumo.com

Field note 01 / Cybersecurity & AI risk

When signals
become decisions.

Four questions for people building or evaluating connected systems: what is visible, what can act, what changed and who is responsible?

A useful way to examine cybersecurity risk is to follow the path from an event to a consequential action. What was observed? How was it interpreted? What could happen next? This perspective becomes especially relevant when an AI component can use tools or interact with other systems.

The four questions below are an editorial synthesis. They are a starting point for discussion, not a complete assessment or a claim that any one product solves the problem.

01 / Visibility

Can you reconstruct what happened?

The NCSC and its international partners recommend monitoring AI system behavior and logging inputs in line with privacy requirements. The purpose includes identifying changes, investigating misuse and supporting a response. See the operation and maintenance section of the secure AI development guidelines.

For a project discussion, separate “we have logs” from “we can answer a question.” Imagine someone reports an unexpected action. Which records would connect the request, the system version, the permission used and the result? Which gaps would leave the explanation uncertain?

Ask the team

What evidence would let another person understand this event without relying on the memory of the person who investigated it?

02 / Permission

What can the system actually do?

OWASP describes excessive agency as a risk when an LLM-based application has more functionality, permissions or autonomy than it needs. Unexpected or manipulated outputs can then cause damaging actions. Its guidance includes narrower tools, reduced permissions and independent approval of consequential actions. Read OWASP’s Excessive Agency entry.

Consider a hypothetical assistant that prepares a proposed infrastructure change. Drafting that proposal and applying it to production are different authorities. A useful review makes the transition explicit: what authorizes execution, what enforces that authorization and what happens if the proposal is wrong?

Ask the team

Where is the boundary between a recommendation and an action, and what enforces it outside the model’s own response?

03 / Change

What became different after the review?

The NCSC guidelines highlight that changing data, models or prompts can change system behavior. They recommend treating significant updates as new versions and supporting evaluation of those changes. See secure operation and maintenance.

A practical discussion can begin with an ordinary release question: what assumptions did the previous review depend on? A model replacement, a new external source or an additional tool can each be a reason to revisit those assumptions. Keep the conversation tied to the actual change rather than a generic claim that the system was already checked.

Ask the team

Which change would cause us to repeat an evaluation, limit a capability or pause a release?

04 / Responsibility

Who owns the decision and the response?

NIST’s Cybersecurity Framework 2.0 makes Govern one of its six core functions, alongside Identify, Protect, Detect, Respond and Recover. It treats cybersecurity as an organizational risk-management concern, with strategy, expectations and policy connected to the other functions. Read NIST CSF 2.0.

For a meeting, try following one unresolved issue across the organization. Who can explain it, who can authorize a change, and who will confirm the result? A clear answer is more useful than a slide saying that security is everyone’s responsibility.

Ask the team

Who has the authority, information and time to act when this particular risk needs attention?

A discussion to take away.

Choose one real workflow. Write down one observation, one permission boundary, one change that would trigger review and one accountable owner. If an answer is missing, record it as an open question rather than filling the gap with an assumption.

This exercise is a conversation starter, not a scoring system or certification. The source documents below provide wider context and should be read for the needs of the actual system.

Primary sources.

  1. NIST Cybersecurity Framework 2.0Published February 26, 2024. Governance and cybersecurity risk outcomes.
  2. Guidelines for secure AI system developmentNCSC, CISA and international partners, 2023. Security across the AI system lifecycle.
  3. LLM06:2025 Excessive AgencyOWASP Gen AI Security Project. Tools, permissions and autonomy in LLM applications.

These sources support the discussion. Their inclusion does not imply endorsement of Sigumo or this domain.

Why this perspective sits here

The path from signal to attention is the creative link to Sigumo. The article describes a field of work; it does not claim that Sigumo operates a security product or service.

Read the Sigumo naming story