AvengerAI

Abilities Table
Group Task
Human Approval
Redaction
Audit Log
Immunity System
Architecture
Dashboard
Admin Center

Inspiration

AI Agents are becoming capable of reading files, modifying workspaces, running commands, using external services, and collaborating with other Agents. However, giving an Agent more capability also creates more opportunities for mistakes, misuse, credential exposure, and unexpected behaviour.

We wanted to answer a simple question:

How can users trust an Agent without giving it unlimited power?

This inspired Avenger AI: a governance layer where every Agent has a defined power set, suspicious actions are detected before execution, sensitive information is protected, and important decisions remain visible to the user.

What it does

Avenger AI makes Agent activity safer and easier to understand.

Users can create Agents with least-privilege abilities such as reading the workspace, writing files, running commands, accessing secrets, using the network, or joining shared sessions. These abilities are enforced on the backend rather than being treated as frontend-only restrictions.

Before a Run reaches the Agent Runtime, Avenger AI:

Classifies the capabilities required by the prompt.
Checks the Agent’s allowed abilities.
Detects suspicious behaviour using the Agent Immune System.
Calculates an explainable risk score.
Allows, holds for human review, or denies the request.
Records the decision in the audit history.
Redacts secrets from outputs, errors, messages, audit events, logs, and API responses.

The Agent Immune System detects threats such as prompt injection, credential access, sensitive resource access, data exfiltration, suspicious network access, workspace escape, destructive actions, and privilege escalation.

Avenger AI also supports group tasks. Users can mention multiple Agents, and the coordinator routes turns through a shared session while preserving the order and identity of every Agent’s contribution.

The dashboard provides a system-wide view of Agent statuses, Run outcomes, token usage, denial trends, common errors, and recent policy or Immune System denials.

How we built it

Avenger AI was built as a backend middleware layer integrated with the existing Agent Launchpad.

The backend stores Agents, Runs, messages, permissions, audit events, Immune events, and Immune Memory. Agent abilities are checked before the Agent Runtime is called.

The Agent Immune System uses configured threat patterns and weighted risk signals. Similarity matching allows confirmed threats to be stored as normalised fingerprints. Future prompts can be compared with these fingerprints, allowing previous security decisions to influence later risk scores.

Human approval is handled at the individual Run level. High-risk requests can enter a pending_approval state until the user explicitly approves or denies that specific Run.

Secret redaction is implemented as a shared backend utility. Runtime configuration values are passed into the redaction layer, which recursively processes strings, arrays, and nested objects. Values are replaced with [REDACTED] before they are persisted, logged, returned by the API, or displayed.

For multi-Agent coordination, a GroupTaskCoordinator creates a shared session, identifies Agents from @mentions, selects Agents in round-robin order, passes the conversation history to each participant, and records every turn. The coordinator stops when an Agent produces the [TASK COMPLETE] marker or when it detects a timeout, duplicate response, or maximum-turn failure.

Challenges we ran into

One challenge was deciding where security checks should occur. A restriction implemented only in the frontend could be bypassed, so permissions, approval decisions, Immune checks, and redaction had to be enforced in backend service paths.

Another challenge was distinguishing between different reasons a Run could stop. A Run may be denied because the Agent lacks an ability, blocked because of a high Immune risk score, or held because human approval is required. We needed to preserve these decisions clearly in the UI and audit history.

Secret redaction also required careful integration. Initially, test configuration values were loaded through the application configuration but were not available through process.env, so plain test secrets were not detected. We fixed this by passing runtime configuration values directly into the redaction system.

For group tasks, we had to preserve shared context while preventing duplicate turns, skipped turns, infinite loops, and unresponsive Agents.

Accomplishments that we’re proud of

We built a complete governance flow from the frontend prompt to the backend policy layer and Agent Runtime.

We are particularly proud that:

Agent abilities are enforced outside the UI.
High-risk actions can pause for explicit human approval.
Denied requests are recorded with reasons.
The Agent Immune System provides risk scores and explainable threat signals.
Confirmed threats can influence future decisions through Immune Memory.
Secrets are redacted across outputs, errors, messages, audits, Immune events, and group-task data.
Audit events preserve the Agent, Run, session, action, decision, reason, and timestamp.
Multi-Agent tasks preserve shared history and clearly show which Agent produced each turn.
The dashboard turns middleware activity into visible operational and security evidence.
Redaction behaviour is covered by 11 automated tests, including nested data and multiple storage boundaries.

In short, our Avengers do not all have the same powers—and no Agent is allowed to use powers that have not been granted.

What we learned

We learned that Agent safety cannot be treated as a single permission toggle. Effective governance requires several layers working together:

Identity
    ↓
Ability policy
    ↓
Threat detection
    ↓
Risk scoring
    ↓
Human approval
    ↓
Runtime execution
    ↓
Audit and redaction

We also learned that explainability is important. A user should not only see that an action was blocked; they should understand which ability or threat signal caused the decision.

Another key lesson was that security controls must be placed at trusted backend boundaries. UI controls improve the experience, but they cannot be the enforcement mechanism.

Finally, we learned that coordination introduces additional concerns. A multi-Agent system must preserve turn order, shared context, Agent identity, failure handling, and individual permissions for every participant.

What’s next for Avenger AI

Future versions of Avenger AI could include:

Production-grade authentication and role-based access control.
Separate, revocable identities for Agents.
Role-based and delegated approval workflows.
Approval expiry, escalation, and multi-reviewer support.
Durable database storage for audit events and group-task state.
Tamper-evident or append-only audit logs.
Real-time event delivery instead of polling.
More advanced semantic threat detection beyond keyword and regex patterns.
Better Immune Memory management with decay, feedback, and versioned policies.
Custom ability definitions with scoped resources and time-limited permissions.
Dynamic group-task scheduling rather than fixed round-robin turns.
Stronger Agent-to-Agent isolation and session-level privilege boundaries.
Hardened multi-tenant Runtime and container isolation.
Cost budgets, token quotas, concurrency limits, and administrative stop controls.

The long-term goal is for Avenger AI to make powerful Agents feel more like accountable teammates: capable enough to help, constrained enough to trust, and transparent enough to review.

Built With

Submitted to

TikTok TechJam 2026

Created by

I focused on building the Agent Immune middleware and Role-Aware Adaptive Trust system. I implemented risk detection for sensitive Agent actions, human approval flows for uncertain requests, and adaptive trust logic that learns from previous administrator decisions. I also worked on the Admin Approval Center and audit trail, allowing risky actions to be reviewed, approved, rejected, and recorded as evidence. A key part of my contribution was enabling the middleware to recognise behavior patterns across Agents with the same role, so repeated legitimate actions can be auto-approved while unusual or conflicting behavior continues to require human review. I also integrated these features into the existing Agent lifecycle without breaking the baseline runtime and Playground flow.

Sera Suu
I focused on building the Multi-Agent Coordination middleware and its output-validation controls. I implemented a mention-based turn-selection system that lets a user tag which Agents join a task and coordinates them through a shared conversation history, so each Agent sees and builds on what the others just said until the task signals completion. I also worked on threat modeling for Agent output, allowing malformed or unsafe replies, leaked tool-call JSON, echoed prompt content, oversized or combined turns, to be detected, rejected, and recorded rather than silently accepted into the shared task. A key part of my contribution was identifying real abuse cases during testing with a weaker model and turning them into a documented threat model (protected asset, actor, trust boundary, abuse case, controls, residual risk), backed by automated tests proving each control actually catches the failure it targets, at zero token cost. I also integrated these features with the team's Identity/Authorization and Audit systems, so a coordination task inherits the same permission checks and audit attribution as any single-Agent Run, and did this without breaking the baseline runtime and Playground flow.

Marcus Yeong
THAM JODENA _
Goh Min Rui