argus part 3: the event-driven engine

at its core, argus is an event-driven router. it is designed to take an inbound request from any source—a sentinel playbook, a custom webhook, or an itsm callback—and transform it into a meaningful human interaction.

the data flow

the sequence of operations inside the argus engine follows a strict progression:

1. inbound request: a rest api call (post, patch, get, or delete) hits the azure app service endpoint.
2. validation: the engine validates the api key against azure key vault to ensure the request is authorised.
3. extraction: it extracts the technical payload and identifies the requested UI template name.
4. transformation: data is bound to the template using the adaptive cards templating sdk.
5. delivery: the final card is delivered to the correct teams channel or group.

technical architecture: node.js

i chose node.js for the runtime because of its excellent support for asynchronous, non-blocking operations. this is critical for a bot that needs to handle multiple concurrent security alerts without lagging.

• router: an express-based router handles the various rest methods.
• state management: azure table storage logs every transaction with a unique correlation id, allowing us to track an alert from the initial webhook to the final teams post.
• caching: to minimise api latency, the engine implements a local in-memory cache for common definitions and templates.

hardened security with key vault

security automation should never introduce new vulnerabilities. i have integrated argus directly with azure key vault for all credential management.

instead of hard-coding api keys or using local environment variables, argus fetches secrets on demand using managed identities. this ensures that even if the server is compromised, the sensitive keys for itsm tools and security platforms remain secure.

in part 4, we will explore how argus decouples the user interface from the code using adaptive cards and sharepoint.