AI ARCHITECTURE

Local AI. Shared intelligence.

TaraSec is designed so every gateway does not have to consume centrally funded AI. A network owner can choose to run detailed AI assessment at its own gateway, using its own AI account or token, while TaraSec contributes compact cross-network intelligence that no single gateway can see alone.

TWO LEVELS OF AI

Put detailed assessment close to the network. Use central AI where global context matters.

01

Gateway AI

The gateway can build a detailed picture from its own firewall, syslog, TaraSec and other security observations. Because this is the owner's network, the owner can choose the AI provider, model, budget and whether AI assessment is enabled at all.

02

Shared DB intelligence

The TaraSec DB server can cheaply aggregate facts across participants: how many independent owners saw related activity, common targets, known TaraSec network nodes, previous reports, threat history and possible coordinated patterns.

03

Global AI

Central AI can be reserved for questions that genuinely require a network-wide view: botnet discovery, coordinated campaigns, compromised infrastructure and correlations spanning independent networks. It does not need to perform a full paid assessment for every gateway.

04

Local authority

An AI assessment remains evidence, not a verdict. The gateway's defined security policy and, where appropriate, a human administrator remain responsible for enforcement.

WHAT THE GATEWAY SENDS TO AI

Rich local evidence plus compact global context.

The gateway can summarize activity by persistent owner/unit identity rather than forcing the model to guess from changing IP addresses and ports. Local evidence may include event counts, target diversity, services, timing, previous incidents and owner confirmations.

The DB server can add a compact intelligence package describing what the wider TaraSec network knows. This can include independent corroboration, cross-owner observations, candidate botnet relationships and global severity indicators without requiring the central service to pay for the gateway's full AI analysis.

TaraSec also distinguishes customer/LAN units, identified by owner ID plus owner-generated unit ID, from known TaraSec/network nodes, identified as infrastructure, and from genuinely unknown IP-only observations.

THE FEEDBACK LOOP

What one gateway learns can improve protection elsewhere.

01

Observe locally

The gateway produces normalized security evidence from local logs and sensors.

02

Add global context

The gateway receives relevant shared intelligence from TaraSec before assessment.

03

Assess locally

The owner's AI produces structured unit, node, IP-observation and botnet-candidate assessments with severity, confidence and supporting evidence.

04

Report the result

The structured assessment is automatically sent back to the TaraSec DB server. The owner's AI token is never included.

05

Correlate globally

The DB server compares assessments and observations from independent gateways. Agreement across unrelated owners can strengthen a hypothesis; disagreement remains visible rather than being hidden.

06

Improve future context

New correlations become part of the compact intelligence available to gateways, making later assessments better informed.

COST & CONTROL

The gateway owner controls detailed AI consumption.

A gateway owner may provide its own AI credential and decide how often assessment runs. TaraSec should not require every participant's detailed analysis to be paid from one central AI account.

The credential stays at the gateway. It is not stored in the global TaraSec database and is not included when assessment results are reported back. The architecture can support different AI providers or a local model without changing the app's basic security workflow.

The central system can perform much of its work deterministically in SQL and normal software: counts, time windows, matching targets and cross-owner correlations. Global AI is invoked when deeper reasoning adds value.

WHAT GOES BACK TO TARASEC

Share the assessment, not the owner's secret.

Structured findings

Unit assessments, network-node assessments, unresolved IP observations and candidate botnet clusters can be reported with category, severity and confidence.

Evidence metadata

Observation window, event counts, corroboration and evidence fingerprints can help the DB server judge the strength of a result without automatically uploading every raw local log.

Provenance

The DB server records which gateway supplied an assessment and when, allowing later evidence to confirm, weaken or contradict it.

Queued delivery

If the DB server is temporarily unavailable, gateway assessments can be retained locally and delivered when connectivity returns rather than being discarded.

AI IS NOT CONFIRMATION

Suspicion, corroboration and confirmation remain different states.

A gateway AI assessment does not automatically become a globally confirmed infection. TaraSec can retain the model's confidence, the supporting observations, independent corroboration and subsequent history separately.

This is particularly important for false positives and compromised participants. A conclusion becomes more useful when it can be traced back to accountable evidence and compared with observations from independent networks.

SEE IT FROM THE OWNER'S SIDE

The TaraSec App is the gateway owner's control and visibility point.

The app is designed to let an authenticated owner or manager see gateway security status and AI assessments, manage access, request assistance and configure owner-controlled AI without exposing global database credentials.

Read about the TaraSec App →