Security and provenance
AEL, the Agent Engineering Language, checks every package completely before it becomes part of your project, and nothing in a package runs while it is checked or installed. AEL verifies every package before using it, whatever its host: its fingerprint, its contents and how it was built.
Nothing runs when you add a package
- A package never runs an install script. There are no install, build or post-install scripts, and no compiler plug-ins.
- Every package, from OpenEng or from you, is written in AEL and ships as compiled, verified AEL, with no bundled native code. A package that holds a file or a function in another language is refused: your application can hold private functions written in other languages, with typed AEL signatures, built and run with your own toolchains, pinned by version. A package never holds one; see Creating a package.
- A
builddependency never runs inside the compiler, as an install script or by itself during a build; see Kinds. - Checking, compiling and building never contact the registry, change a version or install anything. Nothing downloads when an app starts.
What AEL checks before using a package
| Check | Official packages | Private packages |
|---|---|---|
| Signature | Signed by OpenEng; anything else is refused. | Not signed by OpenEng, and never treated as official. |
| Fingerprint | Matches the signed index, then your lock file. | Matches your manifest and your lock file. |
| Safe file layout | Yes | Yes |
| Contents | Yes | Yes |
| Name and publisher | Yes | Yes |
| How it was built | Yes | Yes |
- Safe file layout. Every path has to stay inside the package's own folder. Links, absolute paths, repeated names, names that differ only in letter case and files over the size limits are refused.
- Contents. The file has to hold compiled AEL only. Every compiled component has to match its description, and every export has to be what the package says it is.
- Name and publisher. The name inside the package has to be the name you asked for, and the publisher the one your manifest names.
- How it was built. The package's build record has to tie it to the AEL source and the toolchain that built it.
The whole file is checked in a temporary place before anything is written into your project. If any check fails, your project is left exactly as it was.
No swapped names
- AEL never treats an external package as an official one, even if its name matches. Official means published and signed by OpenEng on the official registry.
- A private package that cannot be reached never falls back to an official package of the same name.
- An unknown name is an error. AEL never guesses at a misspelled name or picks a package whose name merely looks similar.
- A package's own dependencies come from what its publisher declared. Your project cannot swap them for others by accident, and neither can another package.
Permissions stay yours
A package's capabilities is a request, never a grant. Your deployment decides what a program may do, and a package receives only what your code passes to it. A signature proves who published a package; it grants no permission. See Effects and capabilities.
Pinned, repeatable builds
Your lock file pins the exact versions you built with, so builds repeat, even offline. Your project records every package file's fingerprint, and AEL refuses the file if it ever changes. An official version, once published, never changes.
A skill is a versioned, reusable bundle of instructions, typed tools and functions that an agent or subagent loads through the skills it declares. A run pins each skill it loads by its version and the fingerprint of its instructions, so you can tell which instructions a run used; see Skills.
Knowing what a program contains
Each build records exactly what went into it, so you can check what a program contains. ael refmap shows what references what, for the whole project, one folder or one file, and lists unused code and packages.
Access tokens
Access tokens for your private host stay outside your project files. They never appear in your manifest, your lock file, a package file or AEL's output. See Private packages.
What the checks do not promise
- A fingerprint proves that a file is the one you recorded, not who made it.
- A signature proves that OpenEng published a package. It does not make the package right for your program, and it grants the package no permission.
- Adding a private package from someone else is your decision. Look at the capabilities it asks for before you add it.
Reporting a problem
Security reports go to ael@openeng.ai, the contact address at the foot of every page.