JEGASEC product — agent security
Current status: Working build, open source

AI agents can act. M4ND4TE decides whether they should.

An identity system answers whether a credential is technically permitted to do something. Autonomous AI agents raise a second question no IAM system was built to answer: is this action consistent with the task the agent was actually given? M4ND4TE sits between an agent and its tools and answers that question at the moment of action — allow, block, or hold for a named human — then records the rule behind every decision. Today it is a working build that runs end to end and is published under Apache 2.0, not a fielded or certified system.

Read the source → Discuss a design-partner trial
Demonstrated In validation Not yet claimed
Mandate-scoped authorisation

What M4ND4TE does

An agent holding a credential can use it for anything that credential permits. An agent asked to fix a bug in one repository has no business reading production secrets or creating IAM users — but nothing in a conventional permissions model stops it, because the credential is valid and the request is well-formed. The gap is not authentication. It is that nothing is checking the action against the job.

M4ND4TE makes every tool call an agent attempts pass through an explicit decision first. It evaluates the agent's identity, the mandate it was issued, the policy the organisation set, and what the agent has already done in this session, then returns one of three answers. Rules are deterministic and evaluated in a fixed precedence: an explicit deny always wins, and anything no rule covers is denied by default.

Example decision sequence An agent is issued the mandate "investigate and fix issue #382". It reads the repository (allow), creates a branch (allow), runs the tests (allow), then attempts to merge the pull request — which policy marks as consequential, so it is held for a human (require approval). It then attempts to read production secrets, which an explicit deny rule refuses (block). All five decisions are written to an audit record naming the rule that produced each one.
  • Evaluate every proposed tool call before it reaches the tool
  • Check the action against the agent's assigned mandate, not just its credentials
  • Return allow, block, or hold-for-human-approval
  • Explicit deny always overrides allow; unmatched actions are denied
  • Bind a human approval to the exact request, single-use and expiring
  • Record every decision, with its reason, on a tamper-evident trail
The moat

The mandate is the control surface

Guardrails inside a model are commodities, and sandboxing a process is well-trodden. Every agent framework will ship a permissions file. The defensible layer is the object those permissions are written against. A conventional model scopes a credential to a principal: this agent may touch these systems, indefinitely, for whatever reason. M4ND4TE scopes authority to a mandate: this agent may touch these systems, for this task, until this task ends. The same agent with the same credentials gets a different answer as the job changes — which is the behaviour an operator actually wants, and the one a principal-scoped model cannot express.

What a mandate is A mandate is a first-class record: the task an agent was issued, the scope it implies, and the window it is valid for. Policy is evaluated against the mandate rather than the credential, so authority contracts when the task narrows and expires when the task ends — instead of persisting as a standing grant that nobody revokes.

A different object

Anyone can scope a token to a service. Scoping authority to the task an agent was assigned, and re-deciding as that task moves, is a different model to the role- and credential-based stacks M4ND4TE sits above rather than replaces.

Explainable, not a black box

Every decision names the rule that produced it. Enforcement is deterministic rather than model-based, which is what a security team needs before it will let an autonomous system act unsupervised — and what an auditor needs afterwards.

Vendor-neutral by construction

The interface is a plain HTTP call, not a plugin for one agent framework. The same policy core applies whatever the agent is built on, so the control does not have to be rewritten each time the runtime underneath it changes.

Stated plainly Mandate-scoped evaluation is demonstrated today: the decision sequence above runs end to end against a sandboxed executor, and the source is public. The specific policies shipped in the repository are illustrative examples, not an organisation's real rule set; the architecture is what a partner's real policy plugs into.
Run it yourself →

Source, policy examples and the end-to-end demonstration are published at github.com/gobijega/m4nd4te under Apache 2.0 — the evidence for every claim on this page.

Evidence, stated plainly

What runs today, and what's next

Demonstrated now
  • A deterministic policy engine with wildcard rules and deny precedence
  • Agent, mandate and policy management over an HTTP API
  • Human approval workflow with single-use, expiring, request-bound grants
  • An append-only, hash-chained audit trail with integrity verification
  • Automatic redaction of sensitive parameters before they are logged
  • A Python client library and tool wrapper, against a sandboxed executor
In validation
  • Integration with a real agent runtime rather than a controlled harness
  • Policy authoring a security team, not an engineer, can own
  • Behaviour under sustained real-world agent load
  • A first design-partner trial, once one is confirmed
Not yet claimed
  • Deployment against any organisation's live agent fleet
  • Security certification, audit or independent assessment
  • Performance or latency figures from real-world operation
  • Managed hosting, SSO, RBAC or multi-tenancy
  • Customers, contracts, pilots or trials
From working build to operational validation

The path to the field

M4ND4TE's decision logic is demonstrated today, and anyone can verify that by running it. The next milestones are about proving it in front of agents that touch systems where an unintended action would matter. This is the stage where a design partner changes everything.

01

Working open-source build

Policy engine, mandates, approvals and hash-chained audit demonstrated end to end against a sandboxed executor, published under Apache 2.0.

Where we are today
02

Real runtime integration

Enforce against a production agent framework and its real tool surface, rather than a controlled harness.

Next milestone
03

Policy a security team can own

Authoring, review and change control for policy that does not require the person writing it to be the person who built the agent.

In validation
04

Design-partner trial

Run in front of an external organisation's agents, against systems with real consequences, and measure what it actually caught.

Seeking partners
05

Operationalisation

Hardening, transport security, SSO and role-based access, decision export into existing SIEM tooling, and assurance appropriate to the deployment.

Future

Longer-term roadmap, not claimed today: evaluating whether a proposed action matches a stated objective rather than a written rule, behavioural baselines across agent sessions, and anomaly detection on agent behaviour over time.

Why it's built this way

Deterministic first, intelligent later

  • Rules decide, not a model: a fixed evaluation order means the same request always produces the same answer, and can be reasoned about before deployment
  • Deny by default: an action no policy anticipated is refused rather than permitted, so a gap in a policy fails safe
  • Explainable: every decision names the rule behind it, which is what makes an audit trail worth reading
  • Approval that means something: a human approval is bound to the exact request and usable once, so it cannot be redirected to a different action
  • Tamper-evident: audit records are hash-chained, so an altered or removed record is detectable rather than silent
  • Open by default: the enforcement logic is published, because a control nobody can inspect is a control nobody should trust

A model-based evaluator can be added later as an additional check. It is deliberately not on the enforcement path today: a control that decides differently on identical input is not one an organisation can rely on, or explain to an auditor. This is the same discipline behind Continuity's policy engine — autonomy is only acceptable when every decision it makes can be reconstructed afterwards.

What this is not

Boundaries, stated plainly

  • Not a fielded, operational or certified system — a working build, published as source
  • Not deployed with any customer, and not sold as a hosted service
  • Not a replacement for identity and access management — an additional layer above it
  • Not a guarantee against prompt injection or a misbehaving model: it constrains what an agent can do, not what it can be persuaded to attempt
  • Not an offensive security capability of any kind
  • It cannot enforce anything on a tool path that does not route through it

The honest summary: M4ND4TE narrows what a compromised, confused or over-eager agent can reach, and makes what it did reviewable afterwards. That is a smaller claim than "safe AI agents", and it is the one the software actually supports.

Design partners

Point it at agents that touch something real.

JEGASEC is seeking design partners already running AI agents against systems where an unintended action would matter, and who today have no way to constrain those agents at runtime or to reconstruct afterwards what they did. Software engineering organisations, managed service providers, financial operations and critical-infrastructure operators are all natural fits. None of these are current customers; we are looking for the first.

Discuss a design-partner trial Read the source