Om tjänsten
High Level Description
Coding agents can read a repository, call package registries, and edit CI configuration. Those capabilities make them useful, and
they also make a loose default risky: an agent can change the workflow that checks it or pull code from a source the project never
intended. This thesis tests least-privilege setups for that tool use, and measures how often a tight policy blocks ordinary work
versus risky calls.
Who are we looking for?
Purpose
This thesis investigates how least-privilege controls can be applied to the tools a coding agent is allowed to use, and whether
those controls can be tight enough to matter without stopping ordinary development work.
The aim is to move past a single “allow the tools” default by:
- Separating high-impact actions, such as repository write, package installation, and CI-configuration changes, so one task does
not imply the others
- Comparing broader and tighter policies on the same work, including cases where a human checkpoint is more appropriate than a
silent allow or a hard denial
- Measuring both sides of the trade-off: legitimate work that is blocked or delayed, and pre-agreed risky action classes that a
policy allows, denies, or escalates
A proof-of-concept policy layer should be implemented in a small lab and evaluated against a broad baseline. The choice of agent
runtime, CI host, language ecosystems, policy mechanisms, and task set is part of the work, and should be agreed with the
supervisor. Finding new ways to bypass the sandbox is out of scope.
In this thesis, investigate these questions:
- Separation of capabilities. How should repository write, package installation, and CI edits be split so one task does not imply
the others?
- Risky-call coverage. How often do the same policies deny pre-agreed risky classes, such as secret access, CI permission
changes, and fetches outside allowed sources?
- Developer cost. How much extra friction — prompts, approvals, and time — does a tight policy add compared with a broad
baseline?
Workflow fit. Can allows and denials be shown in a way a developer will use?
Scope and Limitations
Scope:
Limitations:
- No production credentials are used in the agent environment.
An Exciting Journey with Knightec Group
Semcon and Knightec have joined forces as Knightec Group. Together, we are Northern Europe’s leading strategic partner in
product and digital service development. With a unique combination of cross-functional expertise and a holistic business
understanding, we help our clients realize their strategies – from idea to complete solution.
Practical Information
This is a thesis position, located at our office in Sundsvall. Start date January or March 2027.
Please submit your application as soon as possible, but no later than 2026-11-30. If you have any questions, you are welcome to
contact johanna.edstrom@knightec.se. Note that due to GDPR, we only accept applications through our careers page.