Security & Research

Security engineering and research, led by Thanat Manasakool.

Thanat Manasakool, Founder & Principal Engineer, is the Security Lead of Factor I O Co., Ltd., responsible for security architecture, defensive research, vulnerability assessment and the development of secure AI infrastructure systems across the company's work.

Who is responsible for security.

The person accountable for security architecture and research at Factor IO, stated plainly so it can be checked against the company profile.

Name
Thanat Manasakool
Role
Founder & Principal Engineer, Security Lead
Organisation
Factor I O Co., Ltd. (registration 0105562205512), Bangkok, Thailand
Responsibilities
Security architecture, defensive research, vulnerability assessment, and the development of secure AI infrastructure systems.
Security contact
admin@factor-io.com

Security leadership across governance and infrastructure.

Factor IO's security leadership oversees the architecture and development of defensive security capabilities across the company's AI governance and infrastructure automation work. Responsibilities include security research, vulnerability assessment, agent authorization boundaries, credential protection, infrastructure hardening and the development of controlled security automation. Current engineering initiatives include Light, an AI agent governance platform, and Light Ops Box, an infrastructure security and operations solution under development. Thanat brings nearly 20 years in enterprise infrastructure, including time as an Ecosystem Solutions Architect for Red Hat and Nutanix.

Three areas of defensive security engineering.

The disciplines the security work is organised around. All of it is defensive: finding weaknesses so they can be fixed, and proving that the fix holds.

  • AI agent security

    Agent identity and authorization boundaries. Least-privilege tool execution and policy enforcement. Prevention of prompt injection and unauthorized actions. Credential isolation and secrets management. Governed execution with an audit trail.

  • Vulnerability research and CVE assessment

    Analysis of publicly disclosed CVEs. Whether a vulnerability applies, and how exposed a system really is. Operating system, container, Kubernetes and infrastructure security. Exploitability analysis for defensive risk assessment. Patch prioritisation and validation that remediation worked.

  • Infrastructure security automation

    Security configuration assessment. Compliance and hardening validation. Governed remediation workflows. Security operations automation. Repeatable verification that defensive controls still hold.

What is in use today, and what is still being built.

Implemented capabilities and work under development are listed separately, so nothing planned reads as available.

Light · in use
AI agent governance platform, used in the company's own reference deployment. An agent declares the files and commands it intends to touch before it acts, and anything outside that declaration is refused. An independent model reviews the plan, a person approves it, and releases run in one ordered queue with a receipt linking plan, reviewer and commit. Enforcement covers actions routed through Light; commands run outside a Light session are outside automatic coverage.
light-tools · open source
The agent file and shell tools, plan engine and safety gates, published on GitHub under GPL-3.0-or-later.
Light Ops Box · under development
An infrastructure security and operations solution. It is under development and is not generally available.

Where the research is carried out.

Factor IO conducts defensive security engineering and validation only on systems it has the right to test. The purpose is to identify vulnerabilities, validate defensive controls, improve security and see remediation through responsibly.

  1. Company-owned software and infrastructure

    Systems Factor IO builds, owns and operates, including its own products and internal platforms.

  2. Internally controlled development and testing environments

    Environments the company controls end to end, where testing cannot reach anyone else's systems.

  3. Isolated security research laboratories

    Separated lab environments for examining vulnerabilities and exploitability without exposure to production systems or third parties.

  4. Third-party systems, only with explicit authorisation

    Customer or partner systems are tested only when their owner has explicitly authorised it, and only within the agreed scope.

How security work is conducted.

The same rules apply to the company's own systems and to every client engagement.

  • Authorisation and defined scope

    Testing begins only after the owner of the system has authorised it and the scope is defined. Anything outside that scope is out of bounds.

  • Least-privilege access

    People and agents get the narrowest access the task needs, for as long as it needs it.

  • Protecting credentials and customer information

    Credentials are kept out of source code and logs, and handed to tools only when needed. Customer information is used only for the purpose it was shared for.

  • Reproducible testing and verified remediation

    Findings are recorded with the steps to reproduce them, and a fix counts as done only when the same test shows it holds.

  • Responsible handling of findings

    Findings go first to the people responsible for the affected system, stay confidential while a fix is prepared, and are not published without their agreement.

Talk to the architect who will build it.

Tell us what you want to achieve and what you run today. We scope the work and send an itemised quotation within 48 hours.

Request a quotation