SECURITY & RESPONSIBLE AI
Intelligent systems need boundaries.
Capability without control creates operational risk.
Every system we engineer carries three sets of controls: for the AI components, for the software around them, and for anything that touches the physical world. They are designed in during the assessment, not added before launch.
Three control boundaries surround every system: AI controls (11), system controls (9) and edge controls (9). Every control has an owner and is reviewed on a schedule. Human escalation is a control in all three sets.
- 01 · AI CONTROLSWhat the intelligence may see, do and decide
- 02 · SYSTEM CONTROLSHow the software is secured, observed and recovered
- 03 · EDGE CONTROLSHow devices are trusted, updated and kept running
EVERY CONTROL HAS AN OWNER AND IS REVIEWED ON A SCHEDULEHUMAN ESCALATION IS A CONTROL IN ALL THREE SETS
01 · AI CONTROLS
What the intelligence may see, do and decide.
AI is one bounded component of the system. These controls define the boundary: which data it reads, which provider processes it, what it may propose, when it must stop and ask, and how its behaviour is measured over time.
| Nº | CONTROL | WHAT IT MEANS IN PRACTICE | OWNER |
|---|---|---|---|
| 01 | Role-Based AccessThe agent runs under its own identity with the minimum roles its responsibility needs. No inherited admin access. | The agent runs under its own identity with the minimum roles its responsibility needs. No inherited admin access. | SYSTEM OWNER |
| 02 | Data SegregationEach client’s data is isolated. Context passed to a model is scoped to the record in hand, never the whole store. | Each client’s data is isolated. Context passed to a model is scoped to the record in hand, never the whole store. | STACX24 ENGINEERING |
| 03 | Provider SelectionModel provider, region and terms are chosen per system and documented. Self-hosted or edge models where data must not leave. | Model provider, region and terms are chosen per system and documented. Self-hosted or edge models where data must not leave. | CLIENT + STACX24 |
| 04 | Retention ControlsPrompts, outputs and logs have defined retention. Provider training on your data is contractually excluded. | Prompts, outputs and logs have defined retention. Provider training on your data is contractually excluded. | CLIENT |
| 05 | Prompt Injection ConsiderationsUntrusted input is separated from instructions, tool calls are allow-listed, and outputs are validated before use. | Untrusted input is separated from instructions, tool calls are allow-listed, and outputs are validated before use. | STACX24 ENGINEERING |
| 06 | EvaluationA test set and threshold before release; scheduled re-evaluation for accuracy, exceptions and drift. | A test set and threshold before release; scheduled re-evaluation for accuracy, exceptions and drift. | SYSTEM OWNER |
| 07 | Confidence ThresholdsBelow an agreed confidence, the agent does not propose. It routes to a person with what it knows. | Below an agreed confidence, the agent does not propose. It routes to a person with what it knows. | SYSTEM OWNER |
| 08 | Human EscalationConsequential, sensitive or uncertain cases go to a named person. The route cannot be disabled by configuration. | Consequential, sensitive or uncertain cases go to a named person. The route cannot be disabled by configuration. | NAMED HUMAN OWNER |
| 09 | Action LimitsAgents read and propose by default. Any act permission is explicit, scoped, logged and approved. | Agents read and propose by default. Any act permission is explicit, scoped, logged and approved. | NAMED HUMAN OWNER |
| 10 | Fallback BehaviourIf the model is unavailable or fails validation, the system falls back to rules or to a person. Never to silence. | If the model is unavailable or fails validation, the system falls back to rules or to a person. Never to silence. | STACX24 ENGINEERING |
| 11 | Usage MonitoringCalls, tokens, cost and latency per agent, per outcome, visible to the owner and reported monthly. | Calls, tokens, cost and latency per agent, per outcome, visible to the owner and reported monthly. | SYSTEM OWNER |
APPLIED TO EVERY AGENT AND EVERY MODEL CALL
02 · SYSTEM CONTROLS
How the software is secured, observed and recovered.
The controls any production system should have, applied without exception to the integrations, applications and data stores around the intelligence.
| Nº | CONTROL | WHAT IT MEANS IN PRACTICE | OWNER |
|---|---|---|---|
| 01 | AuthenticationSingle sign-on where available; per-service credentials otherwise. No shared accounts, no long-lived secrets in code. | Single sign-on where available; per-service credentials otherwise. No shared accounts, no long-lived secrets in code. | STACX24 ENGINEERING |
| 02 | EncryptionTLS in transit, encryption at rest, managed keys with rotation. | TLS in transit, encryption at rest, managed keys with rotation. | STACX24 ENGINEERING |
| 03 | LoggingEvery event, decision and action recorded with actor, time and context. Logs are tamper-evident and retained per policy. | Every event, decision and action recorded with actor, time and context. Logs are tamper-evident and retained per policy. | STACX24 ENGINEERING |
| 04 | Error MonitoringExceptions captured, classified and routed. Repeated errors raise to a person. | Exceptions captured, classified and routed. Repeated errors raise to a person. | STACX24 ENGINEERING |
| 05 | ObservabilityHealth, throughput, latency and queue depth visible per component in one place. | Health, throughput, latency and queue depth visible per component in one place. | SYSTEM OWNER |
| 06 | BackupsScheduled, encrypted, tested by restore. Retention agreed with the client. | Scheduled, encrypted, tested by restore. Retention agreed with the client. | STACX24 ENGINEERING |
| 07 | RecoveryDocumented recovery objectives and a runbook that has been rehearsed. | Documented recovery objectives and a runbook that has been rehearsed. | STACX24 ENGINEERING |
| 08 | Incident HandlingDefined severity levels, response times, communication and post-incident review with the owner. | Defined severity levels, response times, communication and post-incident review with the owner. | CLIENT + STACX24 |
| 09 | Access ControlLeast privilege for people and services; access reviewed on a schedule; leavers removed the same day. | Least privilege for people and services; access reviewed on a schedule; leavers removed the same day. | CLIENT |
APPLIED TO EVERY INTEGRATION, APPLICATION AND PIPELINE
03 · EDGE CONTROLS
How devices are trusted, updated and kept running.
Physical systems fail physically and are reachable physically. These controls make each device identifiable, updatable and recoverable, and keep the operation running when the network does not.
| Nº | CONTROL | WHAT IT MEANS IN PRACTICE | OWNER |
|---|---|---|---|
| 01 | Device IdentityEach device has a unique, hardware-backed identity and its own credentials. Unknown devices are refused. | Each device has a unique, hardware-backed identity and its own credentials. Unknown devices are refused. | STACX24 ENGINEERING |
| 02 | Secure ProvisioningDevices are enrolled through a controlled process; default credentials never ship. | Devices are enrolled through a controlled process; default credentials never ship. | STACX24 ENGINEERING |
| 03 | Encrypted CommunicationTLS from device to gateway to cloud. Certificates rotate; revoked devices lose access immediately. | TLS from device to gateway to cloud. Certificates rotate; revoked devices lose access immediately. | STACX24 ENGINEERING |
| 04 | OTA StrategySigned over-the-air updates, staged rollout, automatic rollback on failed health checks. | Signed over-the-air updates, staged rollout, automatic rollback on failed health checks. | STACX24 ENGINEERING |
| 05 | Local BufferingReadings stored on the device or gateway during outages and forwarded in order on reconnect. | Readings stored on the device or gateway during outages and forwarded in order on reconnect. | STACX24 ENGINEERING |
| 06 | Offline BehaviourSafety rules and local alerts run without the cloud. Defined, documented and tested on site. | Safety rules and local alerts run without the cloud. Defined, documented and tested on site. | CLIENT + STACX24 |
| 07 | Device HealthHeartbeat, power, storage, temperature and firmware version reported per device; silence raises an alert. | Heartbeat, power, storage, temperature and firmware version reported per device; silence raises an alert. | SYSTEM OWNER |
| 08 | RecoveryWatchdogs, safe restart and remote recovery; a documented path for the rare site visit. | Watchdogs, safe restart and remote recovery; a documented path for the rare site visit. | STACX24 ENGINEERING |
| 09 | Fleet VisibilityEvery device, its state and its owner visible in one view, joined to the operational records. | Every device, its state and its owner visible in one view, joined to the operational records. | SYSTEM OWNER |
APPLIED TO EVERY DEVICE, GATEWAY AND FIELD INSTALLATION
POSITION
Responsible intelligence is an engineering responsibility.
Not a policy document or a pre-launch checklist. Permissions, evaluation, escalation, logging and recovery, built into the system and owned by named people. Ask to see it on any system we have built.
Discuss a System
Security questionnaires and data-processing terms on request.